Software Requirements and the Requirements Engineering Process
Download
Report
Transcript Software Requirements and the Requirements Engineering Process
Software Requirements and
the Requirements Engineering
Process
Chapters 5 and 6
References
Software Engineering. Ian Sommerville. 6th edition.
Pearson.
Code Complete. Steve McConnell. (CC)
The art of requirements triage. Alan M. Davis.
Computer. IEEE. March 2003.
Testing whether requirements are right. Robin F.
Goldsmith, JD. Go Pro Management Inc. NYC Spin
Meeting. December 2004. (RG)
Software Requirements. Karl E. Wieger. Windows
Press.
Dr. Gotel’s research web page
Dr. Barrett’s slides, NYU
What is a requirement?
It is about WHAT not HOW
Nothing can be said obvious
Requirements are the descriptions of the services
provided by a system and its operational constraints
It may range from a high level abstract statement to
a detailed mathematical specification
It may be as complex as a 500 pages of description
It may serve as the basis for a bid for a contract or
the basis for the contract itself
What is requirements
engineering?
It is the process of discovering,
analyzing, documenting and validating
the requirements of the system
Each software development process
goes through the phase of requirements
engineering
Why requirements?
What are the advantages of a complete set of
documented requirements?
Ensures the user (not the developer) drives
system functionalities
Helps avoiding confusion and arguments
Helps minimizing the changes
Changes in requirements are expensive.
Changing the requirements costs:
3 x as much during the design phase
5-10 x as much during implementation
10-100 x as much after release [Code Complete,
p30]
Why requirements?
2/3 of finished system errors are
requirements and design errors [RG]
A careful requirements process doesn’t mean
there will be no changes later
Average project experiences about 25% changes
in the requirements
This accounts for 70-80% if the rework of the
project [Code Complete, p40]
Important to plan for requirements changes
The case of critical applications
Different levels of abstraction
User requirements (abstract +)
Usually the first attempt for the description of the
requirements
Services and constraints of the system
In natural language or diagrams
Readable by everybody
Serve business objectives
System requirements (abstract -)
Services and constraints of the system in detail
Useful for the design and development
Precise and cover all cases
Structured presentation
Example
User requirement: The library system should
provide a way to allow a patron to borrow a book
from the library.
System requirement: The library system should
provide a withdraw interaction that allows a
patron to withdraw a book given the isbn and
copy number of the book to be withdrawn. The
interaction fails if: the book is already withdrawn,
the book is not in the library's collection, the
patron has already withdrawn 5 books, the patron
owes more than $5, the book is on hold by
someone else. Otherwise…(To be completed)
Types of requirements
Functional requirements
Non-functional requirements
Constraints on the services or functions offered by the system
Examples: Timing constraints, constraints on the development
process (CASE, language, development method…), standards etc
Domain requirements
Services the system should provide
What the system should do or not in reaction to particular
situations
From the application domain of the system
May be functional or non-functional
Examples: Medicine, library, physics, chemistry
Note: You can have user/system functional/non-functional
requirements.
User requirements
First attempt to describe functional and nonfunctional requirements
Understandable by the user
Problems:
Lack of clarity - ambiguous language
Requirements confusion - functional, non-functional
requirements, design information are not distinguished
Requirements amalgamation – several requirements are
defined as a single one
Incompleteness – requirements may be missing
Inconsistency – requirements may contradict themselves
User requirements
Guideline to minimize the issues:
Separate requirements – separate the requirements,
separate functional and non-functional requirements,
requirements must be clearly identified (e.g. by a number)
Include a rationale for each requirement – helps clarify
reasoning behind the requirements and may be useful for
evaluating potential changes in the requirements
Invent or use a standard form/template
Distinguish requirements priorities
Example: MoSCoW (Must, Shall, Could, Want/Will (no TBD))
Avoid technical jargon
Testable (write test cases)
Deliverables
System requirements
Elaborate the user requirements to get a
precise, detailed and complete version of
them
Used by designers and developers
An important aspect is how to present/write
system requirements
Natural language is often used!
The difference between user and system
requirements must not be thought as a detail
System requirements
Example: If sales for current month are below
target sales, then report is to be printed
unless difference between target sales and
actual sales is less than half of difference
between target sales and actual sales in
previous month, or if difference between
target sales and actual sales for the current
month is less than 5%.
Problems:
Difficult to read
Ambiguity: sales and actual sales, 5% of what?
Incomplete: what if sales are above target sales?
Writing system requirements
Natural language (informal requirements)
Structured natural language
Forms/templates are used to bring some rigor to natural
language presentations
Graphical notations
Reviled by academics
But widely practiced: everybody can read them, finding a
better notation is hard
Using boxes, arrows… but they mean different things to
different people
Formal specification
Based on logic, state machines…
Hard to understand for many people
An analogy
Archimedes (ca. 250 bc)
Today
Any sphere is equal to 4 times the cone which has
its base equal to the greatest circle in the sphere
and its height equal to the radius of the sphere.
V = 4/3 pi r
3
How is this bit of history relevant for software
requirements?
Formal is better only if everybody understands it
It may take a long time to find a good notation
Software requirements is an area of research
Non-functional requirements
They can be further categorized into:
Product requirements
Organizational requirements
Policies and procedures in the customer’s and developer’s
organizations
Example: Process requirements, implementation requirements,
delivery requirements
External requirements
Factors externals to the system and the development process
Example: Interoperability, legislation, ethics
Non-functional requirements may be more critical than functional
requirements. (The system may be useless…)
Product behavior
Ex: Timing, performance, memory, reliability, portability,
usability
Non-functional requirements
Non-functional
requir ements
Product
requir ements
Ef ficiency
requir ements
Reliability
requir ements
Usability
requirements
Performance
requirements
Or ganizational
requir ements
Portability
requirements
Delivery
requirements
Space
requir ements
External
requirements
Interoperability
requirements
Implementation
requir ements
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements
Non-functional requirements
It is important to be able to test/verify/check
non-functional requirements
Pro perty
Speed
Size
Eas e of u se
Rel iabi li ty
Rob u st ness
P ortabi li ty
Meas ure
P ro cess ed t rans acti o ns /s econ d
User/ Event res po n se ti me
Screen refresh t ime
K By tes
Nu mb er o f RAM ch ip s
Train in g time
Nu mb er o f h elp frames
Mean ti me t o failu re
P ro b ab il ity o f u n av ailab ili ty
Rat e of failu re o ccu rren ce
Av ai lab i lit y
Time to rest art aft er failu re
P ercent ag e o f event s caus in g fail ure
P ro b ab il ity o f d ata co rru pt io n on fail ure
P ercent ag e o f targ et d ep end ent st at ement s
Nu mb er o f t arget sy st ems
Requirements documents
The library system requirements document
(Available in the Blackboard)
Very readable
Some ambiguities
Examples of templates (Available in the
Blackboard):
Microsoft template. Karl E. Wiegers. Software
Requirements. Windows Press.
Volere template
http://www.volere.co.uk
Requirement engineering
5 important activities:
Feasibility study
Requirements elicitation and analysis
Requirements documentation
Requirements validation
Requirements management
Requirement engineering
Feasibility
study
Requirements
elicitation and
analysis
Requir ements
specification
Feasibility
report
Requirements
validation
System
models
User and system
requirements
Requirements
document
Feasibility study
It is done at first to decide whether or
not the project is worthwhile
Look at different perspectives:
Market analysis, financial, schedule,
technical, resource, legal…
Should make you aware of the risks
Feasibility study
Doing the study
Consult information sources: managers,
software engineers, end users…
Based on information collection
(interviews, surveys, questionnaires…)
Should be short (2-3 weeks)
2 examples of feasibility studies are
posted in the Blackboard
Feasibility study
What if the system wasn’t implemented?
What are current process problems?
Do technical resources exist?
What is the risk associated with the technology?
Is new technology needed? What skills?
How will the proposed project help?
How does the proposed project contribute to the
overall objectives of the organization?
Have the benefits identified with the system
being identified clearly?
Feasibility study
What will be the integration problems?
What facilities must be supported by the
system?
What is the risk associated with cost and
schedule?
What are the potential
disadvantages/advantages?
Are there legal issues?
Are there issues linked with the fact that this
is an offshore project?
…