Software Engineering
Tahir Farooq
[Link]@[Link]
Requirement Engineering
Requirements are ... A specification of what should be
implemented. They are descriptions of how the system
should behave, or of a system property or attribute. They
may be a constraint on the development process of the
system.
[Sommerville 1997]
Role of Requirements
Project Planning
Project
Construction Tracking
Process
Software
Requirem
Change
ents
User Control
Documentation
System Testing
Levels of Requirements
Business Requirements
User Requirements
Functional Requirements
Non-Functional Requirements
Business Requirements
These are used to state the high-level business objective of the
organization or customer requesting the system or product
They are used to document main system features and
functionalities without going into their nitty-gritty details
They are captured in a document describing the project vision
and scope
User Requirements
User requirements add further detail to the business
requirements
User requirements are statements of what services the system
is expected to provide to system users and the constraints
under which it must operate.
Functional Requirements
These are statements of services the system should provide, how the
system should react to particular inputs, and how the system should
behave in particular situations
In some cases, the functional requirements may also explicitly
state what the system should not do
Non-Functional Requirements
These are constraints on the services or functions offered by the
system
They include timing constraints, constraints on the development
process, and constraints imposed by standards
Non-functional requirements often apply to the system as a whole, rather
than individual system features or services
Non-Functional Requirements
Non-Functional
requirements
Product Organizational External
requirements requirements requirements
Product Requirements
After completion how much
Efficient in
time require to understand Available
speed of 24 hours.
fully. execution No crash single time
User supportive. Product
requirements
Usability Efficiency Reliability Portability
requirements requirements requirements requirements
Run on multiple
Performance
requirements
Space
requirements
platform(ma os,
window, )
Product Requirements
Reliability and
performance
The system shall allow one hundred thousand hits
per minute on the website
Mean time to failure
The system shall not have down time of more than one
second for continuous execution of one thousand hours
Organizational Requirements
Organizational
requirements
Standards Implementation Delivery
requirements requirements requirements
External Requirements
Relationship with other
External organizations.
requirements
Interoperability Ethical Legislative
requirements requirements requirements
Privacy Safety
requirements requirements
External Requirements
Multiple organization are
going to use your same
product. External
requirements
Therefore software
companies does not give
code and documentation
Interoperability Ethical Legislative
requirements requirements requirements
Privacy Safety
requirements requirements
External Requirements
External
requirements
Interoperability Ethical Legislative
requirements requirements requirements
Privacy Safety
requirements requirements
External Requirements
External
requirements
Interoperability Ethical Legislative
requirements requirements requirements
Privacy Safety
requirements requirements
External Requirements
External
requirements
Interoperability Ethical Legislative
requirements requirements requirements
Privacy Safety
requirements requirements
Telenor
External Requirements
External
requirements
Should
handle by
developer
Critical issues
Interoperability Ethical Legislative
requirements requirements Maintainability issues
requirements
Recovery Issues
Privacy Safety
requirements requirements
External Requirements
The system shall not disclose any personal
information about members of the library system to
other members except system administrators
The system shall comply with the local and national
laws regarding the use of software tools
License
Domain Requirements
Requirements that come from the application domain and
reflect fundamental characteristics of that application
domain
Can be functional or non-functional
These requirements, sometimes, are not explicitly
mentioned, as domain experts find it difficult to convey
them. However, their absence can cause significant
dissatisfaction
Domain Requirements
Domain requirements can impose strict constraints
on solutions Media player
This is particularly true for scientific and engineering
domains
Domain-specific terminology can also cause confusion
Inverse Requirements
They explain what the system shall not do.
Many people find it convenient to describe their needs
in this manner
These requirements indicate the indecisive nature of
customers about certain aspects of a new software
product
Design and Implementation Constraints
They are development guidelines within which the
designer must work, which can seriously limit design
and implementation options
Can also have impact on human resources
Relationship of Several components of Software Requirements
Business Vision and
Requirements Scope document
User Quality
Requirements Attributes
Other
Non-functional
Requirements
Use Case document
System Functional Constraints
Requirements Requirements
Functional Specification Documents
Requirement Origin v/s Costs
Rate of Growth
250% Comparative Cost
200%
150%
100%
50%
0%
Feasibility Requirements Design Coding Testin
g
Some Risks From Inadequate Requirement Process
Insufficient user involvement leads to unacceptable products
Creeping user requirements contribute to overruns and degrade
product quality
Ambiguous requirements lead to ill-spent time and rework
Gold-plating by developers and users adds unnecessary features
Some Risks From Inadequate Requirement Process
Minimal specifications lead to missing key requirements
Overlooking the needs of certain stake holders leads to dissatisfied
customers
Incompletely defined requirements make accurate project
planning and tracking impossible
Ambiguous Requirements
The system should be easy to use by medical staff and should be
organized in such a way that user errors are minimized.
Allows user to cancel sales orders.
The system provides searching of data quickly.
The system is user friendly.
Ambiguous Requirements
Software produces a print normally in ten seconds.
The staff shall be able to use all the system functionalities. The
average number of errors made by users shall not exceed two per
hour of system use.
Ambiguous Requirements
The operator identity consists of the operator name and password;
the password consists of six digits. It should be displayed on the
security screen and deposited in the login file when an operator logs
into the system.
Characteristics of Good Requirements
Numbered
Inspected
Unambiguous
Testable
Complete
Consistent
Understandable
Traceable
Feasible
Modifiable
Task - 1
Write down five functional requirements and five non-
functional requirements of a mobile telephone.
Task - 2
Write down five functional requirements and five non-
functional requirements of an online examination system.
Quality Factors
Portability Correctness
Reusability Reliability
Interoperability Efficiency
Survivability Usability
Safety Integrity
Manageability Maintainability
Supportability Flexibility
Replaceability Testability
Functionality Security
The Problems with our Requirements Practices
We have trouble understanding the requirements that we do acquire
from the customer
We often record requirements in a disorganized manner
We spend far too little time verifying what we do record
We allow change to control us, rather than establishing mechanisms to control
change
Most importantly, we fail to establish a solid foundation for the system or software
that the user wants built
(more on next slide)
Requirements Engineering Tasks
Seven distinct tasks
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements Management
Some of these tasks may occur in parallel and all are adapted to the needs of the
project
All strive to define what the customer wants
All serve to establish a solid foundation for the design and construction of the software
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Inception Task
During inception, the requirements engineer asks a set of questions to establish
A basic understanding of the problem
The people who want a solution
The nature of the solution that is desired
The effectiveness of preliminary communication and collaboration between the customer and
the developer
Through these questions, the requirements engineer needs to
Identify the stakeholders
Recognize multiple viewpoints
Work toward collaboration
Break the ice and initiate the communication
The First Set of Questions
These questions focus on the customer, other stakeholders, the overall goals, and the
benefits
Who is behind the request for this work?
Who will use the solution?
What will be the economic benefit of a successful solution?
Is there another source for the solution that you need?
The Next Set of Questions
These questions enable the requirements engineer to gain a better understanding of the problem and allow the
customer to voice his or her perceptions about a solution
How would you characterize "good" output that would be generated by a
successful solution?
What problem(s) will this solution address?
Can you show me (or describe) the business environment in which the solution
will be used?
Will special performance issues or constraints affect the way the solution is
approached?
The Final Set of Questions
These questions focus on the effectiveness of the communication activity itself
Are you the right person to answer these questions? Are your answers "official"?
Are my questions relevant to the problem that you have?
Am I asking too many questions?
Can anyone else provide additional information?
Should I be asking you anything else?
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Elicitation Task
Eliciting requirements is difficult because of
Problems of scope in identifying the boundaries of the system or
specifying too much technical detail rather than overall system
objectives
Problems of understanding what is wanted, what the problem domain
is, and what the computing environment can handle (Information that is
believed to be "obvious" is often omitted)
Problems of volatility because the requirements change over time
Elicitation may be accomplished through two activities
Collaborative requirements gathering
Quality function deployment
Basic Guidelines of Collaborative Requirements Gathering
Meetings are conducted and attended by both software engineers, customers, and other
interested stakeholders
Rules for preparation and participation are established
An agenda is suggested that is formal enough to cover all important points but informal
enough to encourage the free flow of ideas
A "facilitator" (customer, developer, or outsider) controls the meeting
A "definition mechanism" is used such as work sheets, flip charts, wall stickers, electronic
bulletin board, chat room, or some other virtual forum
The goal is to identify the problem, propose elements of the solution, negotiate different
approaches, and specify a preliminary set of solution requirements
Quality Function Deployment
This is a technique that translates the needs of the customer into technical
requirements for software
It emphasizes an understanding of what is valuable to the customer and
then deploys these values throughout the engineering process through
functions, information, and tasks
It identifies three types of requirements
Normal requirements: These requirements are the objectives and goals
stated for a product or system during meetings with the customer
Expected requirements: These requirements are implicit to the product
or system and may be so fundamental that the customer does not
explicitly state them
Exciting requirements: These requirements are for features that go
beyond the customer's expectations and prove to be very satisfying
when present
QFD process (1)
The basic idea of QFD is to construct relationship matrices between
customer needs, technical requirements, priorities and (if needed)
competitor assessment.
To achieve this the following process is prescribed:
[Link] stakeholders attributes or requirements
[Link] technical features of the requirements
[Link] the requirements to the technical features
[Link] an evaluation of competing products
[Link] technical features and specify a target value for each feature
[Link] technical features for development effort.
QFD process (2)
2
Hows
Competitive
Importance
weighting
weighting
4
Whats
Relationship
matrix
3
Target values
1 Competitive eval. 5
Importance weighting
6
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Goals of Analysis Modeling
Provides the first technical representation of a system
Is easy to understand and maintain
Deals with the problem of size by partitioning the system
Uses graphics whenever possible
Differentiates between essential information versus implementation information
Helps in the tracking and evaluation of interfaces
Provides tools other than narrative text to describe software logic and policy
Analysis Rules of Thumb
The analysis model should focus on requirements that are visible within the
problem or business domain Our concern
Not worried
The level of abstraction should be relatively high about that
about what we
how we will
will implement
implement
Each element of the analysis model should add to an overall understanding of
software requirements and provide insight into the following
Information domain, function, and behavior of the system
The model should minimize coupling throughout the system
Reduce the level of interconnectedness among functions and classes
The model should provide value to all stakeholders
The model should be kept as simple as can be
Analysis Modeling Approaches
Structured analysis
Considers data and the processes that transform the data as separate entities
Data is modeled in terms of only attributes and relationships (but no operations)
Processes are modeled to show the 1) input data, 2) the transformation that occurs
on that data, and 3) the resulting output data
Object-oriented analysis
Focuses on the definition of classes and the manner in which they
collaborate with one another to fulfill customer requirements
Elements of the Analysis
Model
Object-oriented Analysis Structured Analysis
Scenario-based Flow-oriented
modeling modeling
Use case text Data structure diagrams
Use case diagrams Data flow diagrams
Activity diagrams Control-flow diagrams
Swim lane diagrams Processing narratives
Class-based Behavioral
modeling modeling
Class diagrams
State diagrams
Analysis packages
Sequence diagrams
CRC models
Collaboration diagrams
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Negotiation Task
During negotiation, the software engineer reconciles the conflicts between what the customer wants and
what can be achieved given limited business resources
Requirements are ranked (i.e., prioritized) by the customers, users, and other stakeholders
Risks associated with each requirement are identified and analyzed
Rough guesses of development effort are made and used to assess the impact of each requirement on
project cost and delivery time
Using an iterative approach, requirements are eliminated, combined and/or modified so that each party
achieves some measure of satisfaction
The Art of Negotiation
Recognize that it is not competition
Map out a strategy
Listen actively
Focus on the other partys interests
Dont let it get personal
Be creative
Be ready to commit
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Specification Task
A specification is the final work product produced by the requirements engineer
It is normally in the form of a software requirements specification
It serves as the foundation for subsequent software engineering activities
It describes the function and performance of a computer-based system and the constraints that will
govern its development
It formalizes the informational, functional, and behavioral requirements of the proposed software in
both a graphical and textual format
Typical Contents of a Software Requirements Specification
Requirements
Required states and modes
Software requirements grouped by capabilities (i.e., functions, objects)
Software external interface requirements
Software internal interface requirements
Software internal data requirements
Other software requirements (safety, security, privacy, environment, hardware, software,
communications, quality, etc.)
Design and implementation constraints
Qualification provisions to ensure each requirement has been met
Demonstration, test, analysis, inspection, etc.
Requirements traceability
Trace back to the system or subsystem where each requirement applies
Software Requirements Specification (SRS) template
TABLE OF CONTENTS
1.0 Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2.0 General Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions and Dependencies
SRS template
3.0 Specific Requirements
3.1 Functional Requirements
3.1.1 Unit Registration
3.1.2 Retrieving and Displaying Unit Information
3.1.3 Report Generation
3.1.4 Data Entry
3.2 Design Constraints
3.3 Non-Functional Requirements
3.3.1 Security
Appendix A
SRS explained
1.0 INTRODUCTION
This document specifies all the requirements for
1.1 Purpose
The purpose of the is to .
The system should assist .
The intended audience for this document is
This specification describes ..
1.2 Scope
This document applies only to ...
This specification is not concerned with ..
SRS explained
1.3 Definitions, Acronyms, and Abbreviations
SRS - Software Requirements Specifications
IEEE - Institute of Electrical and Electronic Engineering
1.4 Reference
[1] IEEE 830-1993: IEEE Recommended Practice for Software Requirements
Specifications" IEEE Standards Collection, IEEE, 1997.
1.5 Overview
In the following sections of this specificationwill be presented.
In Section 2, the general product and its functions will be introduced.
SRS explained
In Section 3, all detailed requirements will be specified and grouped.
In Appendix .
2.0 GENERAL DESCRIPTION
2.1 Product Perspective
This system allows stakeholders to..
The system will display..
The system will help
The system provides information about .
2.2 Product Functions
The system provides the following functions:
SRS explained
2.3 User Characteristics
The users of the system are:
Level of Users Computer Knowledge
Level of Users Business Knowledge
Frequency of Use
2.4 General Constraints
The system will support .
The system will not allow
2.5 Assumption and Dependencies
This system relies on
The system must have a satisfactory interface and
Section 3 of SRS
3 SPECIFIC REQUIREMENTS
3.1 Functional Requirements
3.1.1 Unit Registration
The unit registration requirements are concerned with functions
regarding unit registration which includes students selecting, adding,
dropping, and changing a unit.
SRS-001 ([Link]):
The system shall allow the user to register a unit.
SRS-002 ([Link]):
STS shall allow the user to delete a unit if the user has chosen to drop that unit.
SRS-003 ([Link]):
STS shall check if a unit has been filled by enough registered students .
SRS functional egs
SRS-004 ([Link]):
STS shall allow the user to add his/her name to the unit waiting list if the user
wants to register in a unit which has been filled already with enough
registered students.
SRS-005 ([Link]):
STS shall automatically register the unit for the user who is the first one on
the waiting list if a vacancy appears for that unit.
SRS-006 ([Link]):
STS shall allow the user to change practical session(s) within a unit.
SRS-007 ([Link]):
STS shall allow the user to change tutorial session(s) within a unit.
Functional parent reqs broken into many child-reqs.
3.1.2 Retrieving and Displaying Unit Information
The retrieving and displaying requirements are concerned with how
information is retrieved and presented to the user.
SRS-014 ([Link]):
The system shall allow users to enter the following selection criteria to
retrieve unit information: by unit code, by unit number, by title of unit, by
weight of unit (credit points).
OR by unit code ([Link].1) , by unit number ([Link].2) , by title of unit
([Link].3) , by weight of unit (credit points) ([Link].4).
Design Constraints (3.2)
3.2 Design Constraints
SRS-031 (3.2.1):
STS shall store and retrieve persistent data.
SRS-032 (3.2.2):
STS shall support PC and/or UNIX platforms.
SRS-033 (3.2.3):
STS shall be developed using the JAVA programming language
Non-functional requirements
3.3 Non-Functional Requirements
SRS-034 (3.3.1):
STS shall respond to any retrieval in less than 5 seconds.
SRS-035 (3.3.2):
STS shall generate a report within 1 minute.
SRS-036 (3.3.3):
STS shall allow the user to remotely connect to the system.
SRS-041 (3.3.8):
The system will be accompanied by a comprehensive user manual.
Safety and security issues
3.5.3 Security
The security requirements are concerned with security and privacy issues.
SRS-029:
VSS shall provide staff ID and password verification protection to protect
from unauthorised use of the system.
SRS-030:
VSS shall allow the store manager to add, remove and modify staff ID and
passwords as required.
Other SRS template for section 3
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communication Interfaces
3.2 Functional Requirements
3.2.1 Requirement 1
[Link] Introduction
[Link] Inputs
[Link] Processing
[Link] Outputs
3.2.2 Requirement 2 ..
Other SRS template for section 3
3.3 Performance Requirements
3.4 Design Constraints
3.4.1 Standards Compliance
3.4.2 Hardware Limitations
3.5 Software System Attributes
3.5.1 Reliability
3.5.2 Availability
3.5.3 Security
3.5.4 Maintainability
3.5.5 Portability
3.5.6 Reusability
3.5.7 Usability 3.5.8 Other Factors ..
3.6 Other Requirements
3.6.1 Database
3.6.2 Operations ..
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Validation Task
During validation, the work products produced as a result of
requirements engineering are assessed for quality
The specification is examined to ensure that
all software requirements have been stated unambiguously
inconsistencies, omissions, and errors have been detected and corrected
the work products conform to the standards established for the process, the
project, and the product
The formal technical review serves as the primary requirements
validation mechanism
Members include software engineers, customers, users, and other stakeholders
Questions to ask when Validating Requirements
Is each requirement consistent with the overall objective for the
system/product?
Have all requirements been specified at the proper level of abstraction?
That is, do some requirements provide a level of technical detail that is
inappropriate at this stage?
Is the requirement really necessary or does it represent an add-on feature
that may not be essential to the objective of the system?
Is each requirement bounded and unambiguous?
Does each requirement have attribution? That is, is a source (generally, a
specific individual) noted for each requirement?
(more on next slide)
Questions to ask when Validating Requirements (continued)
Do any requirements conflict with other requirements?
Iseach requirement achievable in the technical environment that will house
the system or product?
Is each requirement testable, once implemented?
Approaches: Demonstration, actual test, analysis, or inspection
Does the requirements model properly reflect the information, function, and
behavior of the system to be built?
Has the requirements model been partitioned in a way that exposes
progressively more detailed information about the system?
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Requirements Management Task
During requirements management, the project team performs a set of
activities to identify, control, and track requirements and changes to the
requirements at any time as the project proceeds
Each requirement is assigned a unique identifier
The requirements are then placed into one or more traceability tables
Requirements Management Task
These tables may be stored in a database that relate features,
sources, dependencies, subsystems, and interfaces to the
requirements
A requirements traceability table is also placed at the end of the
software requirements specification
Summary
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management