SE-381Software Engineering

BEIT-V

Lecture no. 15

Requirements Engineering (1 of 3)

Recap– Till now, we have covered, various models for

Software Development Process– In home reading, Ch-02 of Pankaj Jalot; An Integrated

Approach to Software Engineering, 2005; the remaining processes i.e.• Project Management Process, Software Configuration

Process, Inspection Process and Process Management Process

• ISO and CMM Processes for assuring quality and improving the process of sw development or Process Management Process

were to be read and covered by yourselves, but were covered in class as well.

– Now we move on the different phases of Software Development Process

Feasibility Study

Requirements Engineering or Specification

Ref: Ch – 4 ‘ Requirements Engineering’ of [Bel05]Ch – 3 ‘Software Requirements Analysis and Specifications’ [Jal05]

Ch – 10 ‘Requirements’ [Sch07] and Ch-7 ‘Requirements Phase’ [Sch96]

• 1st stage of Sw Development, it is to know ‘What’ does user want

• User could be the client, sometimes very naïve and ignorant but sometimes ‘too’ smart to believe computers could do everything as in science fiction movies

• Requirements provided by the user are usually very vague, ill-defined and ambiguous, and you are lucky, if otherwise

• One of the most important phases of the SD and consumes about 33% of the SD effort

• Unless we can precisely define ‘What is needed’ we cannot implement it

• After determining Requirements Specification, then it is used through out that how well the system is implemented and system is verified that it don’t contain errors - Verification

• Eradication of Requirement Specification errors cost 200-400 times more for their correction in implementation or later stages, secondly, about 50% of errors are generated from this phase

• Easy to write poor Requirement Specifications than to write good precise specifications.

• Requirements Specifications cannot be written once and frozen, instead these keep changing as the system is developed and user requirements are clarified and refined.

• Engineers have been writing them for generations, For example Requirement Specification for a Railway Locomotive:

On a dry track, the locomotive must be able to start a train of up to 1000 tonnes on an incline of up to 30% with an acceleration of at least 30 km/h/h

• Requirements Engineering consists of Requirement Elicitation, Requirements Analysis and Requirements Specification; three parts, the Output is SRS Document

• SRS tells us, ‘What does the user want?’ in above case the user is the Railway company

• Don’t discuss the ‘How’ part, i.e. how it is going to be implemented, Eg in above case, no mention of fuel being used by the locomotive, or wheel arrangement etc

• It provides measures for Testability of the product here load carrying capacity, slope and acceleration

• At Requirement Specification stage, Whether the implementation constraints should be considered? Or not!

– For – Not as the user is not knowledgeable and would complicate the requirements

– Against – Yes, for legacy systems, most of the Requirement Specs are coming from the implemented system’s design; For some complicated systems, say, Response time of ½ second of the system, required by the user may not be technically possible on a low-end P-IV machine, so better not to commit.

Qualities of a Specification / SRS• Specification should confine to ‘What’ part• A good Specification should have following characteristics:

– Implementation free – What is needed, not How it is achieved– Complete – there is nothing missing– Consistent – no individual requirement contradicts any other– Unambiguous – each requirement has single interpretation– Concise – each requirement is stated once only, without

duplication– Minimal – there are no unnecessary ingredients – Understandable – by both the client and the developers– Achievable – the requirement is technically feasible– Modifiable – as writing SRS is an iterative process to

accommodate changes it should be easy to update or change– Traceable – all requirements could be traced forward to Design

and Code (and so should have reference)– Testable – it can be demonstrated that requirements can be

met• The above could be used as a Checklist when Requirement

Specifications are drawn and to examine and improve them

• Apply the above checklist on

Write a JAVA program to provide a personal telephone directory. It should implement functions to look up a number and to enter a new telephone number. The program should provide a friendly user interface.

and Compare it with the specification of locomotive i.e.

On a dry track, the locomotive must be able to start a train of up to 1000 tonnes on an incline of up to 30% with an acceleration of at least 30 km/h/h

• In Natural language, vagueness and clarity (single interpretation) are common problems, hence instead of informal methods, some semi- formal and formal methods are introduced, but these constrain the users understandability of SRS document

• SDLs (Specification Description Languages) have been devised and other graphical-cum-textual methods are used

• PSL/PSAs Problem Statement Languages and Problem Statement Analyzers and RSL (Requirements Statement Languages) REVS (Requirements Engineering Validation Systems) have been introduced to help System Analysts but these are very domain (and author) specific [Jlo98;pp53-55]

Requirements Engineering Phase

– Requirements Engineering Phase comprises of three parts• Requirements gathering or Elicitation

– Listening part – developer listens to and discusses with the users/clients to get their requirements

• Requirements Analysis – Thinking part – developers transform the users requirements

into a form that these can be delivered by the system• Requirements Specification

– Writing part – developers write down the SRS document• Output – is Software Requirements Specifications (SRS) a

formal document that can be used for Verification (during the development process) and Validation (by the Client at the end of development) of the produced product.

• SRS is a keynote deliverable and there are many approved formats by different standardization authorities, like IEEE 1987 and 1994 standards.

• Requirements gathering and Analysis – Different methods like interviews, surveys, discussions, meetings,

visits, questionnaires etc are used to elicit information from the user and client

– Information is systematically recorded and using different methods it is analyzed, modeled and confirmed from the user and deficiencies, if any, are removed. Usual methods are

» Data Flow Diagrams – to demonstrate or model data flows in the system

» Entity Relationship Diagrams – to identify main data structures and sources in the system

» Structured Charts – to show different parts of the system and their interfaces

» Data Dictionary – to correlate the definition and use of different data elements by different components of the system

» Structured English – to write down the working of different components of the system

– The top two are the methods for Requirements Analysis and they form the basis for Architectural and Detailed Design Stages as well.

– These all are related to the INTERNAL structure of the program, helping to understand and model that HOW the required functionality will be provided

– For EXTERNAL structure we use USE CASE Model to identify what different users or stakeholders are expecting from the system. This concentrates on What part.

– Use Cases are the descriptions of various scenarios and interactions which will benefit the Users of the system

• Requirements Specifications– The findings of Requirements Elicitation and

Requirements Analysis stages are documented – The essential components of the SRS Document are …

Components of an SRS Document

• The SRS Document must address the following basic issues. And this can also work as checklist for the contents of SRS document.

– The Functional Requirements– The Data Requirements– Performance Requirements– Design Constraints imposed on an implementation– External Interfaces– Guidelines

• The Functional Requirements– These are the real essence of SRS, – They state what the system should do.– Verbs characterize the functions to be performed

• The Data Requirements – should include– Users’ data i.e. input/output of the system via any of the I/O

devices Keyboard, mouse, Screen etc– Data that is stored within the system– Information passed to or from another user or a computer system

• Performance Requirements – are the measures of performance, sometimes needed to test the system

– Cost, Delivery date, Response time– Data volumes – must store the data of 180M Pak Nationals– Throughput or Loading levels – 1K transactions per min– Reliability Requirements – MTBF (mean Time Between Failures)

be 6 months– Security Requirements – unauthorized access to enter data

• Constraints – are influences on the implementation of the system Eg The system must be written in JAVA; Application to find Qibla and Prayer Timings for iPhone (eg Salat-o-Falah by Jin Technologies)

– These may be related to Hw, Memory Available, Programming Language, Interoperability (can Salat-o-Falah be ported to Andriod platform?)

• Guidelines – provide useful direction for the implementation in situation where there may be more than one implementation strategy

References for the lecture

[Bel05] Douglas Bell; Software Engineering for Students, 4th Ed, Pearson Education, LPE, New Delhi, Ch-4

[Jal91,Jal97, Jal05] Pankaj Jalote; Integrated Approach to Software Engineering; Revised and 2nd Editions, Narosa Publishing House, New Delhi, Ch-2, 3rd Edition Ch-3

[Sch96] Stephen R Schach; Classical and OO Software Engineering, 3rd Edition, McGraw Hill Inc. Ch-7 ‘Requirements Phase’

[Sch07] Stephen Schach; Software Engineering, 7th Edition, Tata McGraw Hill Publishing Co, New Delhi, Ch-10 ‘Requirements’

[IEE87] IEEE, Software Engineering Standards, IEEE Press, 1987

[IEE94] IEEE, IEEE Software Engineering Standards Collection, 1994 Edition, IEEE Press, 1994

Home Reading

– [Jal97] Ch-3 sections relating to Requirement Analysis and SRS Document Formats

– [Bal05] Ch-4 ‘Requirements Engineering’ and Ch-3 ‘Feasibility Study’