Software Engineering, Lectures

1. SE-381
Software Engineering
BEIT-V
Lecture no. 15
Requirements Engineering (1 of 3)

2. 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

3. Feasibility Study

4. 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

5. • 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

6. • 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.

7. 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

8. • 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.

9. 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]

10. 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.

11. • 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

12. – 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 …

13. 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

14. • 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

15. 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

16. Home Reading
– [Jal97] Ch-3 sections relating to Requirement
Analysis and SRS Document Formats
– [Bal05] Ch-4 ‘Requirements Engineering’ and
Ch-3 ‘Feasibility Study’