2. Requirements in Software Development
Requirements
Operation and
MaintenanceImplementation
Design
Feasibility and
Planning
All process
models include a
requirements
activity
3. Requirements Engineering
• Requirements may be
• functional or non-functional:
– Functional requirements describe system
services or features .
– Non-functional requirements is a constraint on
the system or on the development process.
5. Requirements Analysis and
Definition
The requirements analysis and definition establish the system's
services, constraints and goals by consultation with users. They
are then defined in a manner that is understandable by both
users and development staff.
This phase can be divided into:
• Requirements analysis
• Requirements definition
• Requirements specification
Requirements define the function of the system from the
client's viewpoint.
6. Goals during the requirements
phase
• Understand the requirements in detail (analysis).
• Describe the requirements in a manner that is clear to the client.
Ensure that the client understands the description of the
requirements and their implications.
• Describe the requirements in a manner that is clear to the people
who will design and implement the system.
The Requirements Documentation is the defining document
that describes the goals of the system that is being built.
It may form a legal contract between client and software developers.
7. Requirements analysis:
interviews with clients
Should reflect accurately what the client wants . Client interviews
are the heart of the requirements analysis and definition.
Clients may have only a vague concept of requirements.
• Allow plenty of time.
• Prepare before you meet with the client
• Keep full notes
• If you do not understand, delve further, again and again
• Repeat what you hear
• Small group meetings are often most effective
8. Requirements analysis
1. Identify the stakeholders:
• Who is affected by this system?
Client
Senior management
Production staff
Computing staff
Customers
etc., etc., etc.,
2. Understand the requirements in depth:
• Domain understanding
3. Organize the requirements:
• Classification into coherent clusters
9. New and old systems
In requirements analysis it is important to distinguish:
• features of the current system
• proposed new features
Clients often confuse the current system with the
underlying requirement.
A new system is when there is no existing system.
A replacement system (or subsystem) is when a system is
built to replace an existing system.
A legacy system is an existing system that is not being
replaced, but must interface to the new system.
10. Functional requirements
Requirements about the functions that the system
must perform that will be identified by analyzing
the use made of the system
• Functionality
• Data
• User interfaces
11. Non-functional requirements
Requirements that are not directly related to the
functions that the system must perform
Product requirements
performance, reliability, portability, etc...
Organizational requirements
delivery, training, standards, etc...
Marketing and public relations
12. Example of non-functional
requirements
Example: Library of Congress Repository
Use systems that the client's staff are familiar with:
• Hardware and software systems (IBM/Unix)
• Database systems (Oracle)
• Programming languages (C and C++)
Recognize that the client is a federal library:
• Regulations covering government contracting
• Importance of developing a system that will be
respected by other major libraries
13. The Requirements Document
• The requirements document is the official
statement of what is required of the system
developers.
• Should include both a definition and a
specification of requirements.
• It is NOT a design document. As far as
possible, it should set out WHAT the system
should do rather than HOW it should do it.
14. Requirements Document Requirements
• Specify external system behavior.
• Specify implementation constraints.
• Easy to change.
• Serve as reference tool for maintenance.
• Record forethought about the life cycle of
the system i.e., predict changes.
• Characterize responses to unexpected
events.
15. Requirements Document Structure
• Introduction (Requirements Definition)
– Describe need for the system and how it fits with business
objectives.
• Functional Requirements
– Describe the services to be provided in detail.
• Non-functional Requirements
– Define constraints on the system and the development
process.
• System Evolution
– Define fundamental assumptions on which the system is
based and anticipated changes.
• Glossary
– Define technical terms used.
• Index
16. System-level Requirements
• Some requirements place constraints on the
system as a whole rather than specific system
functions.
• Example
– The time required for training a system
operator to be proficient in the use of the
system must not exceed 2 working days.
• These may be emergent requirements which
cannot be derived from any single sub-set of the
system requirements
17. Requirements Traceability
• Requirements traceability means that
related requirements are linked in some
way and that requirements are (perhaps)
linked to their source.
• Traceability is a property of a requirements
specification which reflects the ease of
finding related requirements.
18. Traceability Techniques
• Assign a unique number to all
requirements.
• Cross-reference related requirements
using this unique number.
• Use HTML hyperlinks to implement
traceability.
19. Requirements Verifiability
• Requirements should be written so that they can be
verified objectively.
• The problem with this requirement is its use of vague
terms such as “errors shall be minimized”
– The system should be easy to use by experienced
controllers and should be organized in such a way
that user errors are minimized.
• The error rate should be been quantified.
– Experienced controllers should be able to use all the
system functions after a total of two hours training.
After this training, the average number of errors made
by experienced users should not exceed two per day.
20. Requirements Measures
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size K Bytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restartafter failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependentstatements
Number of target systems
21. 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.
• Prototyping is an important technique of
requirements validation.
22. 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?
23. 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.
