SOFTWARE REQUIREMENTS ENGINEERING

LECTURE # 10

Refining the System Definition

(Software Requirements)

3rd July, 2013 Engr. Ali Javed

 Instructor Information
2

 Course Instructor: Engr. Ali Javed

Assistant Professor
Department of Software Engineering
U.E.T Taxila
 Email: ali.javed@uettaxila.edu.pk
 Website: http://web.uettaxila.edu.pk/uet/UETsub/perSites/mySite.asp?frmEmail=ali.javed@uettaxila.edu.pk
 Contact No: +92-51-9047747
 Office hours:
 Monday, 09:00 - 11:00, Office # 7 S.E.D

 Lab Instructor: Engr. Asra, Engr. Sobia

Engr. Ali Javed

 Course Information
3

 Course Name: Software Requirements Engineering

 Course Code: SE-203

 CMS Link: http://web.uettaxila.edu.pk/CMS/SP2013/seSREbs/

Engr. Ali Javed

 4 Presentation Outline
 Software Requirements
 Software System Behavior
 Relationship between Features and Software Requirements
 The Requirements Dilemma
• Excluding Project Information

• Excluding Design Information

 Requirements VS Design
 Iteration between Requirements & Design
 Characterization Of Requirements
• Functional Requirements

• Non-Functional Requirements

• Design Constraints

Engr. Ali Javed

 Looking Deeper into Software
Requirements
5

 A software requirement is defined as a software capability that must be met or possessed by a

system or a system component to satisfy a contract, standard, specification, or other formally
imposed documentation

 Since now, we've been speaking of these requirements things as features and use cases at a
fairly high level of abstraction. It was sufficient to understand the system at a macro-level view.

 However, as we get closer to implementation, additional specificity is required.

 Software requirements are those things that the software does on behalf of the user.

 The first place to look for Software requirements is around the boundary of the system, in
addition certain characteristics like performance, reliability etc. also needs to be considered.

Engr. Ali Javed

 Software System Behavior
6

 Davis [1999] suggests that we need five major classes of things in order to
fully describe the behavior of a software system (Figure 1).

 Inputs to the system— not only the content of the input but also, as necessary, the
details of input devices and the form, look, and feel of the input.

 Outputs from the system— a description of the output devices, such as voice- output or
visual display, that must be supported, by the system.

 Functions of the system— the mapping of inputs to outputs, and their various combinations.

 Attributes of the system— such typical non-behavioral requirements as reliability,

maintainability, availability, etc.

 Attributes of the system environment— such additional non-behavioral requirements as the

ability of the system to operate with other applications, loads, and operating systems.

Engr. Ali Javed

 Software System Behavior
7

Figure 1:: System elements

Engr. Ali Javed
 Relationship between Features and Software
Requirements
8

 There is a mapping relationship between features and software requirements.

Vision Document Feature Software Requirements

Features are simple descriptions of systems Software requirements, represented in any
services described in a brief form. form, express those features in much more
detailed terms.
The Vision Document cites features in user’s The Software Requirements express those
language. features in technical terms, using one or more
specific Software requirements that must be
fulfilled by the developer in order to provide
the features to the user

Engr. Ali Javed

 Relationship between Features and Software
Requirements
9

 For example, suppose we are developing a defect-tracking system for a software

development organization.
 Table 1 shows the relationship between one of the features identified in the Vision
document and its associated set of requirements.
 This mapping will form the backbone of a requirements management concept known
as "traceability“.

Table 1:: Prioritized Features List

Vision Document Feature Software Requirements
Feature 30: The defect-tracking system will SR30.1:Trending information will be provided in
provide trending information to help the user a histogram report showing time on the x-axis
assess project status. and number of defects on the y-axis
SR30.2: The user can enter the trending period
In units of days, weeks or months.
SR30.3: An example trending report is shown in
Attached Figure1.

Engr. Ali Javed

 The Requirement Dilemma : What Vs How
10

Engr. Ali Javed

 The Requirement Dilemma : What Vs How
11

 As we have seen, requirements tell the developers what their system must do.

 But there's a lot of other information that the requirements should not contain, they should avoid
specifying any unnecessary design or implementation details, or testing and information
associated with project management.

 This is "what versus how" paradigm,

 where what represents the requirements, and

 how represents the design or other project information that is to be implemented to achieve this
objective.

Engr. Ali Javed

 The Requirements Dilemma
12

 Excluding Project Information

 Project-related information (such as schedules, configuration management

plans, verification and validation plans etc.) is sometimes bundled into the
set of requirements for the convenience of the project manager. In general,
this must be avoided since changes in this information increase volatility and
the tendency for the "requirements" to be out of date.

Schedules Verification and Validation

Engr. Ali Javed

 The Requirements Dilemma
13

 Excluding Project Information

 The budget could be seen as requirement too; however, this is

another type of information that doesn't fit our definition and
therefore doesn't belong with the overall system or software
requirements.

Engr. Ali Javed

 The Requirements Dilemma
14

 Excluding Project Information

 Information describing how we'll know that the requirements have

actually been met — test procedures or acceptance procedures—
also don't meet the definition and therefore don't belong in the
requirements.

Engr. Ali Javed

 The Requirements Dilemma
15

 Excluding Design Information

 The requirements should also exclude information about the system design or
architecture. Otherwise, you may accidentally restrict your team from following
whatever design options make the most sense for your application.

 Suppose, for example, that the requirement in Table 1 had been worded like
this: "Trending information will be provided in a histogram report written in
Visual Basic, showing major contributing causes on the x-axis and the
number of defects found on the y-axis" (Figure 2).

Engr. Ali Javed Figure 2:: Pareto Chart

 The Requirements Dilemma
16

 Although the reference to Visual Basic appears to be a violation of the recommended guidelines
(because it doesn't represent any input, output, function, or behavioral attribute), it's useful to ask,
"Who decided to impose the requirement that the histogram be implemented in Visual Basic,
and why was that decision made?“

 Possible answers to that question might include the following.

 One of the technically oriented members of the group defining the Vision document decided that Visual
Basic should be specified because it is the "best" solution for the problem.
 The user may have specified it.
 A process or political decision within the development organization may have mandated that all
applications will be developed with Visual Basic. In an effort to prevent its policies from being ignored,
management insists that references to Visual Basic be inserted whenever possible into requirements
documents.

Engr. Ali Javed

 The Requirements Dilemma
17

 If a technical developer decides to insert a reference to Visual Basic because of a preference

for the language, it obviously has no legitimate place in the list of requirements.

 If the customer refuses to pay for a system unless it's written in Visual Basic, the best course
of action is to treat it like a requirement, although we will place it in a special class, called
design constraints.

 Nevertheless, it's an implementation constraint that has been imposed on the development
team.

Engr. Ali Javed

 Requirements versus Design
18

 So far, we have treated software requirements, design decisions, and design constraints
as if they were distinct entities. That is, we have stated or implied the following.

 Requirements (mostly) precede design

 Users , because they are closest to the need, make requirements decisions.
 Technologists make design decisions because they are best suited to pick, among the many
design options, which option will best meet the need.

Engr. Ali Javed

 Iterating Requirements and Design
19

 In reality, the requirements versus design activities must be iterative.

Requirements discovery, definition, and design decisions are circular. The
process is a continual give and take, in that

Engr. Ali Javed

 20

Are Design Constraints True Requirements?

Engr. Ali Javed

 Requirements Specification
21

 Two terminologies specification & documentation are used interchangeably

 During elicitation, we informally write the requirements
 Now we have to write it in some formal way
 We write it formally so that

 We can have agreement with customer

 We can carry out validation activity
 And as a result we can develop software solutions

Engr. Ali Javed

 Writing Requirements
22

 This document is a starting point for design and development of the software system.

 Typically, requirements documents are written in natural languages (like, English,

Japanese, French, etc.)

 Natural languages, by their nature, are ambiguous.

 For the help of natural languages, structured languages can be used to specify
requirements

Engr. Ali Javed

 Modern SRS Package
23

 Historically the most popular technique for documenting requirements was to use natural
language.

 This technique was revised and improved and eventually a number of standards developed
for these documents, including IEEE 830 standard for Software Requirements Specification.

 The modern SRS package plays no of crucial roles::

 It serves as a basis of communication among all parties

 It represents an agreement among all parties

 It serves as a project manager’s reference standard

 It serves as input to the design, implementation and testing teams

 It controls the evolution of the system throughout development phase of the project

Engr. Ali Javed

 Modern SRS Package
24

Software Requirements Specification

<Project>

Version 1.0 approved

Prepared by <author>

<organization>

<date created>

Engr. Ali Javed

 Modern SRS Package
25

Revision History
Date Revision Description Author
Mm/dd/yy 1.0 Initial Version Author Name

10
Engr. Ali Javed
 Modern SRS Package
26

Table of Contents

1 Introduction
 This section should provide an overview of the supplementary specification and
should contain the following subsections

1.1 Purpose
 Specify the purpose of this SRS. The document collects and organizes all
the requirements of the system. These include functional requirements,
nonfunctional requirements, and design constraints.

1.2 Scope
 State the scope of the document and any systems or subsystems to watch
it applies.

Engr. Ali Javed

 Modern SRS Package
27

1.3 Definitions, Acronyms, and Abbreviations

 Provide the definitions of all terms, acronyms, and abbreviations required to properly
interpret the specification document. This information may be provided by reference to a
project glossary.

1.4 References

 This subsection should

 Provide a list of all documents referenced elsewhere in the specification

 Identify each document by title, report number (if applicable), date, and publishing
organization
 Specify the sources from which the references can be obtained

Engr. Ali Javed

 Modern SRS Package
28

1.5 Assumptions and Dependencies

 List any assumed factors (as opposed to known facts) that could affect the requirements stated
in the SRS. These could include third-party or commercial components that you plan to
use, issues around the development or operating environment, or constraints.
 The project could be affected if these assumptions are incorrect, are not shared, or change.
 Also identify any dependencies the project has on external factors, such as software components that
you intend to reuse from another project etc.

Engr. Ali Javed

 Modern SRS Package
29

2 Use Case Model Survey

 This section provides an overview of the use case model
 This section lists for each use case
 The Use case name
 Brief description explaining use case’s function
 A list of actors for the use case
 Diagram of the use case model

3 Actor Survey
 This section lists the following information for each actor
 The Actor’s name
 Brief description of the actors

Engr. Ali Javed

 Modern SRS Package
30

4 Requirements

4.1 Functional Requirements

 Itemize the detailed functional requirements associated with the features of vision document
 These are the software capabilities that must be present in order for the user to carry out the
services provided by the feature.
 Include how the product should respond to anticipated error conditions or invalid inputs.
Requirements should be concise, complete, unambiguous, verifiable, etc.
 Each requirement should be uniquely identified with a sequence number or a meaningful tag of
some kind.
 REQ-1:
 REQ-2:

Engr. Ali Javed

 Modern SRS Package
31

4 Requirements
4.2 Non-Functional Requirements

 All the non functional requirements associated with the product should be listed
here
 The Non- Functional Requirements can be of the following::

 Usability
 Reliability
 Performance
 Supportability
 Safety
 Security

Engr. Ali Javed

 Modern SRS Package
32

5 User Documentation and Help System

Requirements

 Describes the requirements if any for online user

documentation, help systems, help notices and so on

6 Design Constraints

 This section includes any design constraints on the system

being built.
 Design constraints represent design decisions that have
been mandated and must be adhered to.
 Examples include software languages, prescribed use
of developmental tools, specific architectural constraints,
mandated use of class libraries, and so on.

Engr. Ali Javed

 Modern SRS Package
33

7 Purchased Components

 This section describes any purchased components to be used with the system

8 Interfaces

 This section defines the interfaces that must be supported by the

application
8.1 User Interfaces
8.2 Hardware Interfaces

8.3 Software Interfaces

8.4 Communication Interfaces

Engr. Ali Javed

 Modern SRS Package
34

9 Licensing and Security Requirements

 This section includes any licensing requirements

 This section may also define requirements for security and accessibility, encryption of
source code or user data, and so on.

10 Legal, Copyright, and Other Notices

 This section includes any necessary legal disclaimers, including warranties,
copyright notices, patent notices, or logo.

11 Applicable Standards
 This section includes by reference any applicable standards and the specific
sections of any such standards that apply to the system being built.

Engr. Ali Javed

 Modern SRS Package
35

Index
 The index is provided to assist the reader in locating
the key concepts and topics that occur throughout the
document

Glossary
 Define all the terms necessary to properly interpret
the SRS, including acronyms and abbreviations or other
project or company specific terms necessary for the
understanding of this document and the application

Appendixes
 It includes the details of use case diagrams (Flow of
events, additional paths, preconditions, post conditions etc.)
 Also include other diagrams like ERD diagrams, class
diagrams, state-transition diagrams, Sequence diagrams
etc.

Engr. Ali Javed

 For any query Feel Free to ask
36

Engr. Ali Javed