Lec 9 10

Software Requirements
Software Engineering
What is a requirement?
 It may range from a high-level abstract statement of
a service or of a system constraint to a detailed
mathematical functional specification.
 This is inevitable as requirements may serve a dual
function
• May be the basis for a bid for a contract - therefore must
be open to interpretation;
• May be the basis for the contract itself - therefore must be
defined in detail;
• Both these statements may be called requirements.
Types of requirement
 User requirements
• Statements in natural language plus diagrams
of the services the system provides and its
operational constraints. Written for customers.
 System requirements
• A structured document setting out detailed
descriptions of the system’s functions, services
and operational constraints. Defines what
should be implemented so may be part of a
contract between client and contractor.
Functional and non-functional requirements
 Functional requirements
• Statements of services the system should provide, how
the system should react to particular inputs and how the
system should behave in particular situations.
 Non-functional requirements
• constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.
 Domain requirements
• Requirements that come from the application domain of
the system and that reflect characteristics of that domain.
Requirements engineering processes
 The goal of the REP is to create and maintain a
system requirements document
 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.
RE process - inputs and
outputs
Input/output description
Stakeholders
 Stakeholder analysis:  – Training and user support staff
 • want to make sure the new system is
 Identify all the people who must be
usable and manageable
consulted during information
acquisition  – Business analysts
 • want to make sure “we are doing
 Look for stakeholders associated
better than the competition”
with each of the four worlds
 – Technical authors
 Example stakeholders  • will prepare user manuals and other
 Users concerned with the features documentation for the new system
and functionality of the new system  – The project manager
 Designers  • wants to complete the project on
 • want to build a perfect system, or time, within budget, with all objectives
reuse existing code met.
 Systems/Requirements analysts  – “the customer”

 • want to “get the requirements right”  – External regulators
 • wants to check that the system
meets its legal requirements
The requirements engineering process
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.
 Techniques required to help the discovery:
• Interviews
• Observation
• Scenarios and prototypes
Why do elicitation?
 Not doing elicitation means
• “I do not want to know [or care] what my customer
wants?”
 Resulting in to a system which will not solve real

world problem of the customer.
 The system will not be used and thus fail.
 Return on investment?
ATM stakeholders
 Bank customers
 Representatives of other banks
 Bank managers
 Counter staff
 Database administrators
 Security managers
 Marketing department
 Hardware and software maintenance engineers
 Banking regulators
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 management
 Requirements management is the process of
managing 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

Lec 9 10

Uploaded by

Copyright:

Available Formats

You might also like

Lec 9 10

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lec 9 10

Uploaded by

Copyright:

Available Formats

Software Requirements

 Systems/Requirements analysts  – “the customer”

 Resulting in to a system which will not solve real

 The system will not be used and thus fail.

You might also like