PROCESS MODELS

• Help in the software development

• Guide the software team through a set of framework activities
• Process Models may be linear, incremental or evolutionary

THE WATERFALL MODEL

• Used when requirements are well understood in the beginning

• Also called classic life cycle
• A systematic, sequential approach to Software development
• Begins with customer specification of Requirements and progresses through planning, modeling,
construction and deployment.

Communication
Planning
Modeling
Construction
Deployment

This Model suggests a systematic, sequential approach to SW development that begins at the system
level and progresses through analysis, design, code and testing

PROBLEMS IN WATERFALLMODEL
• Real projects rarely follow the sequential flow since they are always iterative
• The model requires requirements to be explicitly spelled out in the beginning, which is often
difficult
• A working model is not available until late in the project time plan

THE INCREMENTAL PROCESS MODEL

• Linear sequential model is not suited for projects which are iterative in nature
• Incremental model suits such projects
• Used when initial requirements are reasonably well-defined and compelling need to provide limited
functionality quickly
• Functionality expanded further in later releases
• Software is developed in increments
The Incremental Model
 Communication
 Planning
 Modeling
 Construction
 Deployment

Software Engineering Page 11

 INCREMENT 1

Communication
Planning
Modeling
Construction
Deployment

INCREMENT 2

Communication
Planning
Modeling
Construction
: Deployment
:
:
:

INCREMENT N

Communication
Planning
Modeling
Construction
Deployment

THE INCREMENTAL MODEL

• Software releases in increments
• 1st increment constitutes Core product
• Basic requirements are addressed
• Core product undergoes detailed evaluation by the customer
• As a result, plan is developed for the next increment. Plan addresses the modification of core
product to better meet the needs of customer
• Process is repeated until the complete product is produced

THE RAD (Rapid Application Development) MODEL

• An incremental software process model

• Having a short development cycle
• High-speed adoption of the waterfall model using a component based construction approach
• Creates a fully functional system within a very short span time of 60 to 90 days

Software Engineering Page 12

 The RAD Model consists of the following phases:
Communication Planning Construction
Component reuses automatic code generation testing
Modeling
Business modeling Data modeling Process modeling
Deployment integration delivery feedback

THE RAD MODEL

• Multiple software teams work in parallel on different functions
• Modeling encompasses three major phases: Business modeling, Data modeling and process
modeling
• Construction uses reusable components, automatic code generation and testing

Problems in RAD
• Requires a number of RAD teams
• Requires commitment from both developer and customer for rapid-fire completion of activities
• Requires modularity
• Not suited when technical risks are high

EVOLUTIONARY PROCESSMODEL

• Software evolves over a period of time

• Business and product requirements often change as development proceeds making a straight-line
path to an end product unrealistic
• Evolutionary models are iterative and as such are applicable to modern day applications

Software Engineering Page 13

 Types of evolutionary models
– Prototyping
– Spiral model
– Concurrent development model

PROTOTYPING

• Mock up or model( throw away version) of a software product

• Used when customer defines a set of objective but does not identify input, output, or processing
requirements
• Developer is not sure of:
– efficiency of an algorithm
adaptability of an operating system
– human/machine interaction

Communication Quick Plan

Quick Design

Build Prototype Deployment & Delivery

STEPS IN PROTOTYPING
• Begins with requirement gathering
• Identify whatever requirements are known
• Outline areas where further definition is mandatory
• A quick design occur
• Quick design leads to the construction of prototype
• Prototype is evaluated by the customer

Software Engineering Page 14

 • Requirements are refined
• Prototype is turned to satisfy the needs of customer
LIMITATIONS OF PROTOTYPING
• In a rush to get it working, overall software quality or long term maintainability are generally
overlooked
• Use of inappropriate OS or PL
• Use of inefficient algorithm

THE SPIRAL MODEL

An evolutionary model which combines the best feature of the classical life cycle and
the iterative nature of prototype model. Include new element : Risk element. Starts in middle and
continually visits the basic tasks of communication, planning, modeling, construction and deployment

THE SPIRAL MODEL

• Realistic approach to the development of large scale system and software
• Software evolves as process progresses
• Better understanding between developer and customer
• The first circuit might result in the development of a product specification

Software Engineering Page 15

 • Subsequent circuits develop a prototype
• And sophisticated version of software

THE CONCURRENT DEVELOPMENT MODEL

• Also called concurrent engineering

• Constitutes a series of framework activities, software engineering action, tasks and their associated
states
• All activities exist concurrently but reside in different states
• Applicable to all types of software development
• Event generated at one point in the process trigger transitions among the states

A FINAL COMMENT ON EVOLUTIONARY PROCESS

• Difficult in project planning
• Speed of evolution is not known
Does not focus on flexibility and extensibility (more emphasis on high quality)
• Requirement is balance between high quality and flexibility and extensibility

THE UNIFIED PROCESS

Evolved by Rumbaugh, Booch, Jacobson. Combines the best features their OO models. Adopts
additional features proposed by otherexperts. Resulted in Unified Modeling Language(UML). Unified
process developed Rumbaugh and Booch. A framework for Object-Oriented Software
Engineering using UML

PHASES OF UNIFIED PROCESS

• INCEPTION PHASE
• ELABORATION PHASE
• CONSTRUCTION PHASE
• TRANSITION PHASE

The Unified Process (UP)

Software Engineering Page 16

 UNIFIED PROCESS WORK PRODUCTS
Tasks which are required to be completed during different phases
1. Inception Phase
*Vision document
*Initial Use-Case model
*Initial Risk assessment
*Project Plan

2. Elaboration Phase
*Use-Case model
*Analysis model
*Software Architecture description
*Preliminary design model
*Preliminary model

3. Construction Phase
*Design model
*System components
*Test plan and procedure
*Test cases
*Manual

4. Transition Phase
*Delivered software increment
*Beta test results
*General user feedback

Agility and Agile Process model

The meaning of Agile is swift or versatile."Agile process model" refers to a software development
approach based on iterative development. Agile methods break tasks into smaller iterations, or parts
do not directly involve long term planning. The project scope and requirements are laid down at the
beginning of the development process. Plans regarding the number of iterations, the duration and the
scope of each iteration are clearly defined in advance

Software Engineering Page 17

 Phases of Agile model:
1.Requirements gathering
2.Design the requirements
3.Construction/ iteration
4.Testing/ Quality assurance
5.Deployment
6.Feedback

1. Requirements gathering: In this phase, you must define the requirements. You should
explain business opportunities and plan the time and effort needed to build the project.
Based on this information, you can evaluate technical and economic feasibility.

2. Design the requirements: When you have identified the project, work with stakeholders to
define requirements. You can use the user flow diagram or the high-level UML diagram to
show the work of new features and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a working
product. The product will undergo various stages of improvement, so it includes simple,
minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's performance and
looks for the bug.
5. Deployment: In this phase, the team issues a product for the user's work environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback.
Advantages :

1.Frequent Delivery
2.Face-to-Face Communication with clients.
3.Efficient design and fulfils the business requirement.
4.Anytime changes are acceptable.
5.It reduces total development time.

Disadvantges:

1.Due to the shortage of formal documents, it creates confusion and crucial decisions taken
throughout various phases can be misinterpreted at any time by different team members.

Software Engineering Page 18

 2.Due to the lack of proper documentation, once the project completes and the developers
allotted to another project, maintenance of the finished project can become a difficulty.

Extreme Programming
XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop
a software.
eXtreme Programming (XP) was conceived and developed to address the specific needs of
software development by small teams in the face of vague and changing requirements.
Extreme Programming is one of the Agile software development methodologies. It provides
values and principles to guide the team behavior. The team is expected to self-organize.
Extreme Programming provides specific core practices where −
 Each practice is simple and self-complete.

 Combination of practices produces more complex and emergent behaviour.

Other process models of Agile Development and Tools

 Crystal
 Scrum
Scrum
Scrum is aimed at sustaining strong collaboration between people working on complex
products, and details are being changed or added. It is based upon the systematic interactions
between the three major roles: Scrum Master, Product Owner, and the Team.

Software Engineering Page 19

  Scrum Master is a central figure within a project. His principal responsibility is to
eliminate all the obstacles that might prevent the team from working efficiently.
 Product Owner, usually a customer or other stakeholder, is actively involved throughout
the project,conveying the global vision of the product and providing timely feedback on the
job done after every sprint.
 Scrum Team is a cross-functional and self-organizing group of people that is responsible
for the product implementation. It should consist of up to 7 team members, in order to stay
flexible and productive.

Crystal
Crystal is an agile methodology for software development. It places focus on people over
processes, to empower teams to find their own solutions for each project rather than being
constricted with rigid methodologies.
Crystal methods focus on:-
People involved
Interaction between the teams
Community
Skills of people involved
Their Talents
Communication between all the teams

Software Engineering Page 20

 MALLA REDDY COLLEGE OF ENGINEERING & TECHNOLOGY DEPARTMENT
OF INFORMATION TECHNOLOGY

UNIT II
SOFTWARE REQUIREMENTS

IEEE defines Requirement as :

1. A condition or capability needed by a user to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a system or a system component to
satisfy constract, standard, specification or formally imposed document
3. A documented representation of a condition nor capability as in 1 or 2

SOFTWARE REQUIREMENTS
• Encompasses both the User’s view of the requirements( the external view ) and the Developer’s
view( inside characteristics)
User’s Requirements
--Statements in a natural language plus diagram, describing the services the system is expected to
provide and the constraints
• System Requirements --Describe the system’s function, services and operational condition

SOFTWARE REQUIREMENTS
• System Functional Requirements
--Statement of services the system should provide
--Describe the behavior in particular situations
--Defines the system reaction to particular inputs
• Nonfunctional Requirements
- Constraints on the services or functions offered by the system
--Include timing constraints, constraints on the development process and standards
--Apply to system as a whole
• Domain Requirements
--Requirements relate to specific application of the system
--Reflect characteristics and constraints of that system

FUNCTIONAL REQUIREMENTS
• Should be both complete and consistent
• Completeness
-- All services required by the user should be defined
• Consistent
-- Requirements should not have contradictory definition
• Difficult to achieve completeness and consistency for large system

NON-FUNCTIONALREQUIREMENTS
Types of Non-functional Requirements 1.Product Requirements
-Specify product behavior
-Include the following

Software Engineering Page 21

 • Usability
• Efficiency
• Reliability
• Portability
2. Organisational Requirements
--Derived from policies and procedures
--Include the following:
• Delivery
• Implementation
• Standard
3. External Requirements
-- Derived from factors external to the system and its development process
--Includes the following
• Interoperability
• Ethical
• Legislative
PROBLEMS FACED USING THE NATURAL LANGUAGE
1. Lack of clarity-- Leads to misunderstanding because of ambiguity of natural language
2. Confusion-- Due to over flexibility, sometime difficult to find whether requirements are same or
distinct.
3. Amalgamation problem-- Difficult to modularize natural language requirements

STRUCTURED LANGUAGESPECIFICATION
• Requirements are written in a standard way
• Ensures degree of uniformity
• Provide templates to specify system requirements
• Include control constructs and graphical highlighting to partition the specification

SYSTEM REQUIREMENTS STANDARD FORM

• Function
• Description
• Inputs
• Source
• Outputs
• Destination
• Action
• Precondition
• Post condition
• Side effects

Interface Specification
• Working of new system must match with the existing system
• Interface provides this capability and precisely specified

Three types of interfaces

1. Procedural interface-- Used for calling the existing programs by the new programs 2.Data structures-
-Provide data passing from one sub-system to another 3.Representations of Data
-- Ordering of bits to match with the existing system
--Most common in real-time and embedded system

Software Engineering Page 22

 The Software Requirements document
The requirements document is the official statement of what is required of the system developers.
Should include both a definition of user requirements and a specification of the system requirements. It
is NOT a design document. As far as possible ,it should set of WHAT the system should do rather than
HOW it should do it

The Software Requirements document

Heninger suggests that there are 6 requirements that requirement document should satisfy. It should
• specify only external system behavior
• specify constraints on the implementation.
• Be easy to change
• Serve as reference tool for system maintainers
• Record forethought about the life cycle of the system.
• Characterize acceptable responses to undesired events

Purpose of SRS
• communication between the Customer,Analyst,system developers, maintainers, ..
• firm foundation for the design phase
• support system testing activities
• Support project management and control
• controlling the evolution of the system

IEEE requirements standard

Defines a generic structure for a requirements document that must be instantiated for each specific
system.
– Introduction.
– General description.
– Specific requirements.
– Appendices.
– Index.

IEEE requirements standard 1.Introduction

Purpose
Scope
Definitions, Acronyms and Abbreviations
References
Overview
2. General description
Product perspective
Product function summary
User characteristics
General constraints
Assumptions and dependencies
3. Specific Requirements
- Functional requirements

Software Engineering Page 23

 -External interface requirements
- Performance requirements
- Design constraints
- Attributes eg. security, availability, maintainability, transferability/conversion
- Other requirements
• Appendices
• Index
REQUIREMENTS ENGINEERING PROCESS
To create and maintain a system requirement document . The overall process includes four high level
requirements engineering sub-processes:
1. Feasibility study
--Concerned with assessing whether the system is useful to the business 2.Elicitation and analysis
--Discovering requirements 3.Specifications
--Converting the requirements into a standard form 4.Validation
-- Checking that the requirements actually define the system that the customer wants

SPIRAL REPRESENTATION OF REQUIREMENTSENGINEERING PROCESS

Process represented as three stage activity. Activities are organized as an iterative process around a
spiral. Early in the process, most effort will be spent on understanding high-level business and the use
requirement. Later in the outer rings, more effort will be devoted to system requirements engineering
and system modeling
Three level process consists of: 1.Requirements elicitation
2. Requirements specification
3. Requirements validation

Software Engineering Page 24

 FEASIBILITY STUDIES
Starting point of the requirements engineering process
• Input: Set of preliminary business requirements, an outline description of the system and how the
system is intended to support business processes
• Output: Feasibility report that recommends whether or not it is worth carrying out further Feasibility
report answers a number of questions:
1. Does the system contribute to the overall objective
2. Can the system be implemented using the current technology and within given cost and schedule
3. Can the system be integrated with other system which are already in place.

REQUIREMENTS ELICITATION ANALYSIS

Involves a number of people in an organization.

Stakeholder definition-- Refers to any person or group who will be affected by the system directly or
indirectly i.e. Endusers, Engineers, business managers, domain experts.

Reasons why eliciting is difficult

1.Stakeholder often don’t know what they want from the computer system. 2.Stakeholder expression of
requirements in natural language is sometimes difficult to
understand.
3. Different stakeholders express requirements differently
4. Influences of political factors Change in requirements due to dynamic environments.

REQUIREMENTS ELICITATION PROCESS

Process activities
1. Requirement Discovery -- Interaction with stakeholder to collect their requirements including
domain and documentation
2. Requirements classification and organization -- Coherent clustering of requirements from
unstructured collection of requirements
3. Requirements prioritization and negotiation -- Assigning priority to requirements
--Resolves conflicting requirements through negotiation
4. Requirements documentation -- Requirements be documented and placed in the next round of spiral

Software Engineering Page 25

 The spiral representation of Requirements Engineering

REQUIEMENTS DICOVERY TECHNIQUES

1. View points --Based on the viewpoints expressed by the stake holder

--Recognizes multiple perspectives and provides a framework for discovering conflicts in the
requirements proposed by different stakeholders
Three Generic types of viewpoints
1. Interactor viewpoint--Represents people or other system that interact directly with the system
2. Indirect viewpoint--Stakeholders who influence the requirements, but don’t use the system
3.Domain viewpoint--Requirements domain characteristics and constraints that influence the
requirements.

2. Interviewing--Puts questions to stakeholders about the system that they use and the system to be
developed. Requirements are derived from the answers.
Two types of interview
– Closed interviews where the stakeholders answer a pre-defined set of questions.
– Open interviews discuss a range of issues with the stakeholders for better understanding their needs.

Software Engineering Page 26

 Effective interviewers
a) Open-minded: no pre-conceived ideas
b) Prompter: prompt the interviewee to start discussion with a question or a proposal

3. Scenarios --Easier to relate to real life examples than to abstract description. Starts with an outline of
the interaction and during elicitation, details are added to create a complete description of that
interaction
Scenario includes:
• 1. Description at the start of the scenario
• 2. Description of normal flow of the event
• 3. Description of what can go wrong and how this is handled
• 4.Information about other activities parallel to the scenario
• 5.Description of the system state when the scenario finishes

LIBSYS scenario
• Initial assumption: The user has logged on to the LIBSYS system and has located the journal
containing the copy of the article.
• Normal: The user selects the article to be copied. He or she is then prompted by the system to either
provide subscriber information for the journal or to indicate how they will pay for the article.
Alternative payment methods are by credit card or by quoting an organisational account number.
• The user is then asked to fill in a copyright form that maintains details of the transaction and they
then submit this to the LIBSYS system.
• The copyright form is checked and, if OK, the PDF version of the article is downloaded to the
LIBSYS working area on the user’s computer and the user is informed that it is available. The user is
asked to select a printer and a copy of the article is printed

LIBSYS scenario
• What can go wrong: The user may fail to fill in the copyright form correctly. In this case, the form
should be re-presented to the user for correction. If the resubmitted form is still incorrect then the user’s
request for the article is rejected.
• The payment may be rejected by the system. The user’s request for the article is rejected.
• The article download may fail. Retry until successful or the user terminates the session..
• Other activities: Simultaneous downloads of other articles.
• System state on completion: User is logged on. The downloaded article has been deleted from
LIBSYS workspace if it has been flagged as print-only.

4. Use cases -- scenario based technique for requirement elicitation. A fundamental feature of UML,
notation for describing object-oriented system models. Identifies a type of interaction and the actors
involved. Sequence diagrams are used to add information to a Use case

Article printing use-case Ar ticle printing

LIBSYS use cases Article printing Article search

User administration Supplier Catalogue services Library

Software Engineering Page 27

 User Library Staff

REQUIREMENTS VALIDATION
Concerned with showing that the requirements define the systemthat the customer wants. Important
because errors in requirements can lead to extensiverework cost
Validation checks
1.Validity checks --Verification that the system performs the intended function bythe user 2.Consistency
check --Requirements should not conflict
3. Completeness checks --Includes requirements which define all functions andconstraints intended by
the system user
4. Realism checks --Ensures that the requirements can be actually implemented
5. Verifiability -- Testable to avoid disputes between customer and developer.

VALIDATION TECHNIQUES 1.REQUIREMENTS REVIEWS

Reviewers check the following:
(a) Verifiability: Testable
(b) Comprehensibility
(c) Traceability
(d) Adaptability 2.PROTOTYPING

3.TEST-CASE GENERATION

Requirements management
Requirements are likely to change for large software systems and as such requirements management
process is required to handle changes.
Reasons for requirements changes
(a) Diverse Users community where users have different requirements and priorities
(b) System customers and end users are different
(c) Change in the business and technical environment after installation Two classes of requirements
(a) Enduring requirements: Relatively stable requirements
(b) Volatile requirements: Likely to change during system development process or during operation

Requirements management planning

An essential first stage in requirement management process. Planning process consists of the following
1. Requirements identification -- Each requirement must have unique tag for cross reference and
traceability
2. Change management process -- Set of activities that assess the impact and cost of changes
3.Traceability policy -- A matrix showing links between requirements and otherelements of software
development
4.CASE tool support --Automatic tool to improve efficiency of change management process. Automated
tools are required for requirements storage, change management and traceability management

Traceability
Maintains three types of traceability information.
1. Source traceability--Links the requirements to the stakeholders
2. Requirements traceability--Links dependent requirements within the requirements document
3. Design traceability-- Links from the requirements to the design module

Software Engineering Page 28