business requirement slides

1. Business Requirement Analysis –
Session 5
Requirement Specification
Taral Soni
B.Tech (Hons), MBA

2. What we covered in last session
 Requirement Analysis
 Requirement Modeling
 Identifying Requirements
 Prototyping
 Prioritizing requirements

3. Agenda
 Requirement Specification
 Content of SRS
 Attributes of Requirements
 View of requirements

4. Software Requirement
Specification
 How do we communicate the requirements to
others?
 It is common practice to capture them in an SRS
 But it doesn’t need to be a single paper document
 A Structured document setting out detailed
description of the system services. Written as
contract between client and contractor.

5. Software Requirement
Specification
• Purpose • Audience
 Communicates an understanding  User, purchasers
of the requirements  Most interested in system
 Explains both the application requirements
domain and the system to be  Not generally interested in
developed detailed software requirements
 Contractual  System analysis, Requirement
 May be legally binding Analysis
 Express and agreement and a  Write various specifications that
commitment interrelate
 Baseline for evaluating  Developers, programmer
subsequent products  Have to implement the
 Supports system testing, requirements
verification and validation  Tester
activities
 Determine that the
 Should contain enough requirements have been met
information to verify whether the
delivered system meets  Project Manager
requirements  Measure and control the
 Baseline for change control analysis and development
processes
 Requirement changes, software
evolves

6. SRS content
 Software requirement specification should address:
 Functionality – What is software supposed to do?
 External interfaces – How does the software interact with
people, the system’s hardware, other hardware and other
software
 Performance – What is the speed, availability, response
time, recovery time of various software functions, and so
on?
 Attributes – What are portability, correctness,
maintainability, security, and other considerations?
 Design constraints imposed on an implementation – Are
there any standards in effect, implementation language,
policies for database integrity, resource limit, operating
environment and so on?

7. SRS content
 Some other topics should be excluded
 …. Should avoid placing either design or project
requirements in SRS
 …. Should not describe any design or
implementation details. These should be describes
in the design stage of the project
 …. Should address the software product, not the
process of producing the software product.
 SRS Document

8. Typical mistakes
 Noise  Jigsaw puzzle
 The pressure of text that carries no  E.g. distributing requirements across a
relevant information to any feature of the document and then cross referencing
problem
 Duckspeak requirements
 Silence  Requirements that are only there to
 A feature that is not covered confirm the standards
 Over – Specification  Unnecessary invention of terminology
 Text that describes a feature of the  Inconsistent terminology
solution, rather than the problem
 Inventing and then changing terminology
 Contradiction  Putting an onus on development staff
 Text that describes single feature in a
number of incompatible ways  i.e. making the reader work hard to
decipher the intent
 Ambiguity
 Text that can be interpreted in at least
two ways
 Forward reference
 Text that refers to a feature yet to be
defined
 Wishful thinking
 Text that defines a feature that cannot
possibility be validated

9. Ambiguity test
 Natural language?
 “The system shall report to the operator all
faults that originate in critical functions or
that occur during execution of a critical
sequence and for which there is no fault
recovery response.”(adapted from the specifications for the
international space station)

10. Avoid Ambiguity
 Review natural language specs for ambiguity
 use people with different backgrounds
 include software people, domain specialists and user communities
 Must be an independent review (I.e. not by the authors!)
 Use a specification language
 E.g. a restricted subset or stylized English
 E.g. a semi-formal notation (graphical, tabular, etc)
 E.g. a formal specification language (e.g. Z, VDM, SCR, …)
 Exploit redundancy
 Restate a requirement to help the reader confirm her
understanding
 ...but clearly indicate the redundancy
 May want to use a more formal notation for the re-statement

11. Organizing Requirements
 Need a logical organization for the document
 IEEE standard offers different templates. Template attached in previous
slides can also be used
 Example Structures - organize by…
 External stimulus or external situation
 e.g., for an aircraft landing system, each different type of landing situation:
 wind gusts, no fuel, short runway, etc
 …System feature
 e.g., for a telephone system: call forwarding, call blocking, conference call, etc
 …System response
 e.g., for a payroll system: generate pay-cheques, report costs, print tax info;
 …External object
 e.g. for a library information system, organize by book type
 …User type
 e.g. for a project support system: manager, technical staff, administrator, etc.
 …Mode
 e.g. for word processor: page layout mode, outline mode, text editing mode, etc
 …Subsystem
 e.g. for spacecraft: command & control, data handling, comms, instruments, etc.

12. Let’s go through template

13. Requirement Attributes
 User defined attributes
 Priority’
 Risk
 Status
 Iteration
 System Attributes
 Unique ID
 Author
 Revision
 Date
 Entry Point
 Exit point
 Validations
 Success Result

14. Questions