SOFTWARE REQUIREMENTS ENGINEERING LECTURE # 10 · 2013-07-09 · Software requirements are those things that the software does on behalf of the user. The first place to look for Software

3rd July, 2013 Engr. Ali Javed

SOFTWARE REQUIREMENTS ENGINEERING

LECTURE # 10

Refining the System Definition

(Software Requirements)

Instructor Information 2

Course Instructor: Engr. Ali Javed

Assistant Professor

Department of Software Engineering

U.E.T Taxila

Email: [email protected]

Website: http://web.uettaxila.edu.pk/uet/UETsub/perSites/[email protected]

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

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

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

Presentation Outline 4

Engr. Ali Javed

Looking Deeper into Software Requirements

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.

5

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

Figure 1:: System elements

Software System Behavior

Engr. Ali Javed

7

Relationship between Features and Software Requirements

8

There is a mapping relationship between features and software requirements.

Engr. Ali Javed

Vision Document Feature Software Requirements

Features are simple descriptions of systems

services described in a brief form.

Software requirements, represented in any

form, express those features in much more

detailed terms.

The Vision Document cites features in user’s

language.

The Software Requirements express those

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

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

Engr. Ali Javed

Vision Document Feature Software Requirements

Feature 30: The defect-tracking system will

provide trending information to help the user

assess project status.

SR30.1:Trending information will be provided in

a histogram report showing time on the x-axis

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.

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.

Engr. Ali Javed

Schedules Verification and Validation



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



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


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


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


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

Are Design Constraints True Requirements?

20

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


Software Requirements Specification

<Project>

Version 1.0 approved

Prepared by <author>

<organization>

<date created>

Engr. Ali Javed

Revision History

Date Revision Description Author

Mm/dd/yy 1.0 Initial Version Author Name

10


Engr. Ali Javed


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


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


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


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


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


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

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

Modern SRS Package

For any query Feel Free to ask 36

Engr. Ali Javed

Documents

SOFTWARE REQUIREMENTS ENGINEERING LECTURE # 10 · 2013-07-09 · Software requirements are those things that the software does on behalf of the user. The first place to look for Software