Requirements and the Software

Lifecycle
Chapter 2
Prepared by Dr. Hayfa Abu Addous

1
What Is Requirements Management?
 Conformance (or lack of conformance) to a set of
requirements often determines the success (or failure) of
projects.
 Requirements management is a systematic approach to
eliciting, organizing, and documenting the requirements
of the system.
 It is a process that establishes and maintains agreement
between the customer and the project team on the
changing requirements of the system.

2
Types of Software Applications
Information Systems
Informationsystems and other applications developed for use within a
company.(ex: payroll system)
Commercial Products
Softwaredeveloped and sold as commercial products.(ex: MS Office)
Companies developing this type of software are usually referred to as
Independent Software Vendors (ISV)
Embedded Systems
Software that runs on computers embedded in other devices,
machines, or complex systems.(ex: such as those embedded in
cellphones, washing machines, etc.,)

3
Requirements Engineering Processes
Requirements engineering processes
 The processes used for RE vary widely depending on
the application domain, the people involved and the
organisation developing the requirements.
 However, there are a number of generic activities
common to all processes
 Requirements elicitation;
 Requirements analysis;
 Requirements validation;
 Requirements management.
The requirements engineering process

Requir ements
Feasibility elicitation and
stud y
analysis
Requir ements
specification
Feasibility Requir ements
repor t validation

System
models

User and system

requirements

Requir ements
document
Feasibility studies
 A feasibility study decides whether or not the proposed
system is worthwhile.
 A short focused study that checks
 If the system contributes to organisational objectives;
 If the system can be engineered using current technology and
within budget;
 If the system can be integrated with other systems that are
used.
Feasibility study implementation
 Based on information assessment (what is required),
information collection and report writing.
 Questions for people in the organisation
 What if the system wasn’t implemented?
 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?
 Is new technology needed? What skills?
 What facilities must be supported by the proposed system?
Elicitation and analysis
 Sometimes called requirements elicitation or
requirements discovery.
 Involves technical staff working with customers to find
out about the application domain, the services that the
system should provide and the system’s operational
constraints.
 May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These
are called stakeholders.
Problems of requirements analysis
 Stakeholders don’t know what they really want.
 Stakeholders express requirements in their own terms.
 Different stakeholders may have conflicting
requirements.
 Organisational and political factors may influence the
system requirements.
 The requirements change during the analysis process.
New stakeholders may emerge and the business
environment change.
Process activities
 Requirements discovery
 Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
 Requirements classification and organisation
 Groups related requirements and organises them into coherent
clusters.
 Prioritisation and negotiation
 Prioritising requirements and resolving requirements conflicts.
 Requirements documentation
 Requirements are documented and input into the next round of
the spiral.
Requirements discovery
 The process of gathering information about the proposed
and existing systems and distilling the user and system
requirements from this information.
 Sources of information include documentation, system
stakeholders and the specifications of similar systems.
Viewpoints
 Viewpoints are a way of structuring the requirements to
represent the perspectives of different stakeholders.
Stakeholders may be classified under different
viewpoints.
 This multi-perspective analysis is important as there is
no single correct way to analyse system requirements.
Requirements validation
 Concerned with demonstrating that the requirements
define the system that the customer really wants.
 Requirements error costs are high so validation is very
important
 Fixing a requirements error after delivery may cost up to 100
times the cost of fixing an implementation error.
Requirements checking
 Validity. Does the system provide the functions which
best support the customer’s needs?
 Consistency. Are there any requirements conflicts?
 Completeness. Are all functions required by the
customer included?
 Realism. Can the requirements be implemented given
available budget and technology
 Verifiability. Can the requirements be checked?
Requirements validation techniques
 Requirements reviews
 Systematic manual analysis of the requirements.
 Prototyping
 Using an executable model of the system to check
requirements.
 Test-case generation
 Developing tests for requirements to check testability.
Requirements reviews
 Regular reviews should be held while the requirements
definition is being formulated.
 Both client and contractor staff should be involved in
reviews.
 Reviews may be formal (with completed documents) or
informal. Good communications between developers,
customers and users can resolve problems at an early
stage.
Review checks
 Verifiability. Is the requirement realistically testable?
 Comprehensibility. Is the requirement properly
understood?
 Traceability. Is the origin of the requirement clearly
stated?
 Adaptability. Can the requirement be changed without a
large impact on other requirements?
Requirements Management
 In Requirements management we manage changing
requirements during the requirements engineering
process and system development.
 Requirements are inevitably incomplete and inconsistent
 New requirements emerge during the process as business
needs change and a better understanding of the system is
developed;
 Different viewpoints have different requirements and these are
often contradictory.
Requirements change
 The priority of requirements from different viewpoints
changes during the development process.
 System customers may specify requirements from a
business perspective that conflict with end-user
requirements.
 The business and technical environment of the system
changes during its development.
Requirements evolution

Initial Changed
understanding understanding
of pr ob lem of prob lem

Initial Changed
requir ements requir ements

Time
Enduring and volatile requirements
 Enduring requirements. Stable requirements derived
from the core activity of the customer organisation. E.g.
a hospital will always have doctors, nurses, etc. May be
derived from domain models
 Volatile requirements. Requirements which change
during development or when the system is in use. In a
hospital, requirements derived from health-care policy
Requirements classification

Requirement Description
Type
Mutable Requirements that change because of changes to the environment in which the
requirements organisation is operating. For example, in hospital systems, the funding of patient
care may change and thus require different treatment information to be collected.
Emergent Requirements that emerge as the customer's understanding of the system develops
requirements during the system development. The design process may reveal new emergent
requirements.
Consequential Requirements that result from the introduction of the computer system. Introducing
requirements the computer system may change the organisations processes and open up new ways
of working which generate new system requirements
Compatibility Requirements that depend on the particular systems or business processes within an
requirements organisation. As these change, the compatibility requirements on the commissioned
or delivered system may also have to evolve.
Requirements management planning
 During the requirements engineering process, you have
to plan:
 Requirements identification
 How requirements are individually identified;
 A change management process
 The process followed when analysing a requirements change;
 Traceability policies
 The amount of information about requirements relationships that is
maintained;
 CASE tool support
 The tool support required to help manage requirements change;
Traceability
 Traceability is concerned with the relationships between
requirements, their sources and the system design
 Source traceability
 Links from requirements to stakeholders who proposed these
requirements;
 Requirements traceability
 Links between dependent requirements;
 Design traceability
 Links from the requirements to the design;
Requirements change management
 Should apply to all proposed changes to the
requirements.
 Principal stages
 Problem analysis. Discuss requirements problem and propose
change;
 Change analysis and costing. Assess effects of change on other
requirements;
 Change implementation. Modify requirements document and
other documents to reflect change.
Change management

Identified Revised
problem Problem analysis and Change analysis Change requirements
change specification and costing implementation
Key points
 The requirements engineering process includes a
feasibility study, requirements elicitation and analysis,
requirements specification and requirements
management.
 Requirements elicitation and analysis is iterative
involving domain understanding, requirements collection,
classification, structuring, prioritisation and validation.
 Systems have multiple stakeholders with different
requirements.
Key points
 Social and organisation factors influence system
requirements.
 Requirements validation is concerned with checks for
validity, consistency, completeness, realism and
verifiability.
 Business changes inevitably lead to changing
requirements.
 Requirements management includes planning and
change management.
Software Process
Key Points
 The team’s development process defines who is doing
what, when, and how
 The waterfall model
 The spiral model
 The iterative approach

31
Software Process
 Effective requirements management can occur only
within the context of a reasonably well-defined software
process that defines the full set of activities your team
must execute to deliver the final software product.

 The process defines:

 who (which member of the team) is doing
 what (which activity is being performed)
 when (the timing in relation to other activities)
 how (the details and steps in the activity)

32
Waterfall Lifecycle
 Emphasizes full
elaborated
requirements and
Requirements design as a barrier to
exit from a phase
 Not good for large
Design programs, the scope
is large to know all
requirements without
A logical stepwise implementing a
Coding and
process model that portion
unit test
progresses from a
requirements phase
to maintenance System
phase, including integration
feedback loops
O&M

33
Pros and Cons
 Successful in reinforcing the role of requirements, which
form a first step in software development and serve as
the basis for design and coding activities

 Emphasizes fully elaborated requirements and design

documents as a barrier to exit from each phase

 has come to represent a fixed, rigid approach to

development, wherein requirements are "frozen" for the
life of the project, and the process of development takes
on a life of its own, independent of the changes
occurring in the marketplace or in the users' needs.

34
When to use the Waterfall Model
 Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.
 Spiral Model
Cumulative
cost
Determine objectives,
Evaluate alternatives:
alternatives, constraints
identify, resolve risks
Risk
analysis

Risk
analysis

Risk
analysis
Operational
RA Prototype prototype
Prototype Prototype
Commitment
partition Simulatio
Rqtms plan ns, mode
ConOps Software ls, bench
Lifecycle plan marks
rqmts
Software
Rqtms design code
Dev plan validation
Unit
Design test
Int and test plan validation I&T
Accept
test
Plan next phases Implement

Develop, verify next-level product

36
Spiral Model
 Boehm
 Development is initially driven by a series of risk-driven prototypes; then
a structured waterfall-like process is used to produce the final system.
 Starts with requirements planning and concept validation
 A series of prototypes to assist in early confirmation of understanding
 Each prototype is built to validate something, requirements, design,
user-interface, etc.
 Then structure waterfall-like process used to produce the system
 The main advantage of this process is the availability of multiple
feedback opportunities with the users and customers, which is intended
to get the "Yes, Buts" out early.

37
When to use Spiral Model

 When costs and risk evaluation is important

 For medium to high-risk projects
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected
Big bang
 The Big Bang model is an SDLC model where we do not
follow any specific process.
 The development just starts with the required money and
efforts as the input, and the output is the software
developed which may or may not be as per customer
requirement.
 This Big Bang Model does not follow a process/procedure
and there is a very little planning required.
 Even the customer is not sure about what exactly he
wants and the requirements are implemented on the fly
without much analysis.

39
40
 This model is ideal for small projects with one or two
developers working together and is also useful for
academic or practice projects.
 It is an ideal model for the product where requirements
are not well understood and the final release date is not
given.

41
The advantages of the Big Bang Model are as follows −
This is a very simple model
Little or no planning required
Easy to manage
Very few resources required
Gives flexibility to developers
It is a good learning aid for new comers or students.

42
The disadvantages of the Big Bang Model are as follows −
Very High risk and uncertainty.
Not a good model for complex and object-oriented
projects.
Poor model for long and ongoing projects.
Can turn out to be very expensive if requirements are
misunderstood.

43
V-Model
 Under the V-Model, the corresponding testing phase of
the development phase is planned in parallel.
 So, there are Verification phases on one side of the ‘V’
and Validation phases on the other side.
 The Coding Phase joins the two sides of the V-Model.

44
45
The following pointers are some of the most suitable
scenarios to use the V-Model application.
Requirements are well defined, clearly documented and
fixed.
Product definition is stable.
Technology is not dynamic and is well understood by the
project team.
There are no ambiguous or undefined requirements.
The project is short.

46
47
Iterative Model
 Iterative process starts with a simple implementation of a
subset of the software requirements and iteratively
enhances the evolving versions until the full system is
implemented.
 At each iteration, design modifications are made and
new functional capabilities are added.
 The basic idea behind this method is to develop a
system through repeated cycles (iterative) and in smaller
portions at a time (incremental).

48
49
Iterative Model
 Iterative and Incremental development is a combination
of both iterative design or iterative method and
incremental build model for development.
 "During software development, more than one iteration
of the software development cycle may be in progress at
the same time."
 In this incremental model, the whole requirement is
divided into various builds.
 During each iteration, the development module goes
through the requirements, design, implementation and
testing phases.

50
Iterative Model
 Each subsequent release of the module adds function to
the previous release.
 The process continues till the complete system is ready
as per the requirement.
 The key to a successful use of an iterative software
development lifecycle is rigorous validation of
requirements, and verification & testing of each version of
the software against those requirements within each cycle
of the model.
 As the software evolves through successive cycles, tests
must be repeated and extended to verify each version of
the software.

51
Requirements in Iterative Model
 Better adaptability to requirement change
 Requirements are not frozen
 Understood early at a certain level of detail and refined over
time
 Revisited at every iteration
 New requirements can be considered at each iteration
 Better scope management
 If too much was allocated to first iteration, the next iteration can
be adjusted
 Multiple iterations developed by the time the deadline is reached
 Customer will know in advance what is being completed and
what will be delivered when.

52
Agile methodology

Scrum framework
Agile

54
Agile Definition
 Dissatisfaction with the overheads involved in software
design methods of the 1980s and 1990s led to the
creation of agile methods.
 The aim (goal) of agile methods is to:
1. reduce overheads in the software process
(e.g. by limiting documentation) and
2. be able to respond quickly to changing requirements without
excessive rework.
 It has many frameworks including the scrum, Kanban,
hybrid, …ect
 A set of values and principles, it is about focusing on the
items on the left over the items on the right.

56
Agile Definition
It has 12 principles:
[Link] satisfaction by early and continuous delivery of valuable software.
[Link] changing requirements, even in late development.
[Link] working software frequently (weeks rather than months)
[Link], daily cooperation between business people and developers
[Link] are built around motivated individuals, who should be trusted
[Link]-to-face conversation is the best form of communication (co-location)
[Link] software is the primary measure of progress
[Link] development, able to maintain a constant pace
[Link] attention to technical excellence and good design
[Link]—the art of maximizing the amount of work not done—is essential
[Link] architectures, requirements, and designs emerge from self-organizing teams
[Link], the team reflects on how to become more effective, and adjusts
accordingly
The principles of agile methods

Principle Description
1. Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
2. Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each
increment.
3. People not process The skills of the development team should be recognized
and exploited. Team members should be left to develop their
own ways of working without prescriptive processes.
4. Embrace change Expect the system requirements to change and so design
the system to accommodate these changes.

5. Maintain simplicity Focus on simplicity in both the software being developed

and in the development process. Wherever possible,
 
actively work to eliminate complexity from the system
(refactoring).
Chapter 3 Agile software
58 development
Problems with agile methods
 It can be difficult to keep the interest of customers who
are involved in the process.
 Team members may be unsuited to the intense
involvement that characterizes agile methods.
 Prioritizing changes can be difficult where there are
multiple stakeholders.
 Maintaining simplicity requires extra work.
 Contracts may be a problem as with other approaches to
iterative development.

Chapter 3 Agile
59 software development
Agile development
 Specification, design, implementation are inter-leaved

 the outputs from the development process are decided through

a process of negotiation during the software development
process.

62
Scrum Framework
Roles and Responsibilities
 A product owner creates a prioritized wish list called a product backlog.
 During sprint planning, the team pulls a small chunk from the top of that
wish list, a sprint backlog, and decides how to implement those pieces.
 The team has a certain amount of time, a sprint, to complete its work—
usually two to four weeks—but meets each day to assess its progress (daily
Scrum).
 Along the way, the Scrum Master keeps the team focused on its goal.
 At the end of the sprint, the work should be potentially shippable, as in
ready to hand to a customer, put on a store shelf, or show to a stakeholder.
 The sprint ends with a sprint review and retrospective.
 As the next sprint begins, the team chooses another chunk of the product
backlog and begins working again.
 The cycle repeats until enough items in the product
backlog have been completed, the budget is depleted, or
a deadline arrives. Which of these milestones marks the
end of the work is entirely specific to the project.
 No matter which impetus stops work, Scrum ensures
that the most valuable work has been completed when
the project ends.
 Product owner: The person responsible for the business value of the
project and for deciding what work to do and in what order, as documented
in the product backlog.
 Scrum Master: The person who ensures that the team is productive,
facilitates the daily Scrum, enables close cooperation across all roles and
functions, and removes barriers that prevent the team from being effective.
Scrum Masters have authority over the process but not the people on the
team. They must be comfortable surrendering control to the product owner
and team. Some experts suggest that traditional project managers do not
make great Scrum- Masters.
 Scrum team or development team: A cross-functional
team of five to nine people who organize themselves and
the work to produce the desired results for each sprint. A
sprint normally lasts two to four weeks, during which
specific work must be completed and made ready for
review. Large projects might require teams of teams.
Scrum Artifacts
Scrum Artifacts
 In Scrum, an artifact is a useful object created by people. An
artifact can be called a deliverable in other project
management approaches. The following three artifacts are
created with Scrum:
 Product backlog: A list of features prioritized by business
value. The highest priority items should be broken down in
enough detail for the team to estimate the effort involved in
developing them. Some experts suggest scheduling about 10
workdays for each item. Of course, size and complexity of the
work dictates the estimate.
 Sprint backlog: The highest-priority items from the product
backlog to be completed within a sprint. The Scrum team
breaks down the highest-priority items into smaller tasks that
take about 12 to 16 hours to complete
 Burndown chart: Shows the cumulative work remaining in a
sprint on a day-by- day basis.
Scrum Ceremonies
Scrum Ceremonies
 Sprint planning session: A meeting with the team to
select a set of work from the product backlog to deliver
during a sprint and review the prioritized Product
Backlog. This meeting takes about four hours to a full
day.
 Daily Scrum (daily standup): A short meeting for the development team
to share progress and challenges and plan work for the day. Ideally the
team members are in the same place, the meeting usually lasts no
more than 15 minutes, and it is held at the same time and place each
day.
 If that is not possible, teams can use videoconferencing to have short
virtual meetings.
 The Scrum Master asks what work has been done since yesterday,
what work is planned for today, and what impediments or stumbling
blocks might hamper the team’s efforts.
 The Scrum Master documents these stumbling blocks and works with
key stakeholders to resolve them after the daily Scrum.
 Many teams use the term issues for items that do not have to be solved
in the next 24 hours and blockers for items that need to be addressed
immediately.
 This allows a Scrum Master to maintain focus on highest-priority items
(blockers) first and then manage the resolution of other issues over the
next day or so.
 Sprint reviews: A meeting in which the team
demonstrates to the product owner what it has
completed during the sprint.
• Sprint retrospectives: A meeting in which the team looks
for ways to improve the product and the process based
on a review of the actual performance of the
development team.
Agile

Extreme programming (XP)

81
Example of Agile process:
Extreme programming (XP)
 Perhaps the best-known and most widely used agile
method.
 Extreme Programming (XP) takes an ‘extreme’ approach
to iterative development.
 New versions may be built several times per day;
 Increments are delivered to customers every 2 weeks;
 All tests must be run for every build and the build is only accepted
if all tests run successfully.

Chapter 3 Agile
82 software development
XP and agile principles
 Customer involvement means full-time customer
engagement with the team.
 Incremental development is supported through small,
frequent system releases (i.e. every 2 weeks).
 People not process through
1. pair programming,
2. collective ownership, and
3. a process that avoids long working hours (no large amount of overtime).

 Change supported through regular system releases.

 Maintaining simplicity through constant code refactoring
(Improving code quality).

Chapter 3 Agile
83 software development
The XP Release Cycle

Chapter 3 Agile
84 software development
Extreme Programming Practices (a)

Principle or practice Description

Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and
their relative priority. The developers break these stories into
development ‘Tasks’. See Figures 3.5 and 3.6.

Small releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent
and incrementally add functionality to the first release.

Simple design Enough design is carried out to meet the current requirements
and no more.
Test-first development An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.
Chapter 3 Agile
85 software development
Extreme programming Practices (b)

Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that
no islands of develop expertise and all the developers take
responsibility for all of the code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into
the whole system. After any such integration, all the unit tests in
the system must pass.
Sustainable pace Large amounts of overtime are not considered acceptable as
the net effect is often to reduce code quality and medium term
productivity
On-site customer A representative of the end-user of the system (the customer)
should be available full-time for the use of the XP team. In an
extreme programming process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.
Chapter 3 Agile
86 software development
Key Points
 The team’s development process defines who is doing
what, when, and how
 In the waterfall model, software activities proceeded
through a sequence of steps, and requirements were
“fixed” early
 In the spiral model, the first steps were taken to a more
risk-driven and incremental approach to development
 The iterative approach, a hybrid of the waterfall and the
spiral models, decouples the lifecycle phases from the
software activities that take place in each phase
 The iterative model is a more robust model and provides
for successive refinement of the requirements over time

87