Software Engineering - chp2- requirements specification

MedTech

Chapter 2 Requirements Specification

How to write a requirements specification

Dr. L i l ia SFAXIw w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi

Sl id e 1

MedTech Mediterranean Institute of TechnologySoftware Engineering

MedTech

MedTech

Requirements Specification Why?

2

If you dont know where youre going, you will probably end

up somewhere else. Laurence J. Peter

MedTech

SRS: Software Requirements Specification

The organizations understanding, in writing, of a customer or potential clients system requirements and dependencies at a particular point in time, usually prior to any actual design or development work.

A two way insurance policy Insures that both the client and the organization understand the

others requirements from that perspective at a given time

States: The functions and capabilities a software system must provide The required constraints by which the system must abide

Called the parent document

3

Requirements Specification

MedTech

SRS: Major Goals

Providing feedback to the customer SRS is the customers assurance that the dev. organization understands his

needs SRS should be written in a natural language, in an unambiguous manner May include charts, tables, data flow diagrams, decision tables,

Decomposing the problem into component parts The information is organized, borders are placed, ideas solidified

Serving as an input to the design specification As a parent document, it comes prior to the design spec. Must then contain sufficient details about the functional systems

requirements for the design solution to be devised

Serving as a product validation check Is a lso the parent document for testing and validation strategies Is a basis for estimating costs and schedules

4


MedTech

SRS: Content (IEEE 830 standard)

Functionality What is the software supposed to do?

External Interfaces How does the software interact with people, the systems hardware, other

hardware, and other software?

Performance What is the speed, availability, response time, recovery time of various

software functions?

Attributes What are the portability, correctness, maintainability, security, etc .

considerations?

Design constraints imposed on an implementation Are there any required standards in effect, implementation language, polic ies

for database integrity, resource limits, operating environments, etc.?

Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi

Sl id e 5


MedTech

SRS: What it contains, what it doesnt

SRS provides: Function requirements Non-functional requirements

SRS doesnt provide: Design suggestions Possible solutions to technology or business issues

6


MedTech

What makes an SRS a GREAT SRS?

An SRS should be: (IEEE 830 standard) Correct, but also ever correcting

It must be corrected whenever you find incorrect things along the dev or design phases

Unambiguous Every requirement stated therein has only one interpretation Fix ambiguities when found, instead of spending endless time trying to avoid

them

Complete It should be all that is needed by the software designers to create the software

Consistent Within itself and to its reference documents (no contradictions)

Ranked for importance and/or stability Importance and stability (chances of change) for each requirement must be

specified


Sl id e 7


MedTech

What makes an SRS a GREAT SRS?

An SRS should be: (IEEE 830 standard) Verifiable

fast response and the system should never crash are tota lly forbidden statements!

Provide quantitative requirements instead of just suppositions Modifiable

Prefer a shared document to multiple copies Traceable

You should document the life of a requirement and provide bi-directionaltraceability between the associated requirements

Helps find the origin of each requirement and track the changes that were made


Sl id e 8


MedTech

Major Challenge: Requirements Gathering


Sl id e 9


MedTech

Technical Writers..

A technical writer is a professional writer who produces technicaldocumentation that helps people understand and use a product or service

Technical Writers should be involved with SRS And we mean. . to the whole specification writing phase!

Benefits They can gather efficiently the information from the customer They can better assess and plan documentation projects and meet

customer document needs

They know how to determine the questions that are of concern to the user If involved early and often in the gathering process, they can become an

information resource throughout the process, rather than an information gatherer at its end


Sl id e 10


MedTech

Working with Requirements.. A Lifecycle Activity!


Sl id e 11


RequirementsCapture & Definition

Analysis & Design Tools

ModelingTools

SimulationTools

CodingTools

TestingTools

Requirements Management & Traceability Tools

MedTech

Best Practices for Writing Better Requirements

1. Use the simplest words appropriate to state a complete requirement2. Use requirement imperatives correctly


Sl id e 12


Imperatives: words and phrases that command the presence of some feature, functionor deliverable. Listed below in decreasing order of strength.

Shall Used to dictate the provision of a functional capability.

Must or must not Most often used to establish performance requirement or constraints.

Is required to Used as an imperative in SRS statements when written in passive voice.

Are applicable Used to include, by reference, standards, or other documentation as an addition to the requirement being specified.

Responsible for Used as an imperative in SRSs that are written for systems with pre-defined architectures.

Will Used to cite things that the operational or development environment is to provide to the capability being specified. For example, The vehicle's exhaust system will power the ABC widget.

Should Not used often as an imperative in SRS statements; however, when used, the SRS statement always reads weak. Avoid using Should in your SRSs.

MedTech


3. Do not use weak phrases and subjective words Avoid words like: adequate, appropriate, bad, better, but not limited to,

easy, minimize

4. Use continuations carefully, they make traceability difficult Continuances: Phrases that follow an imperative and introduce the

specification of requirements at a lower level. There is a correlation with the frequency of use of continuances and SRS organization and structure, up to a point.

Example: The system shall report software status to the host interface under the following conditions: At system Initia lization When the status of an external interface has changed When a report has been requested

These are actually three requirements


Sl id e 13


MedTech


5. Use examples, tables, figures etc. but make sure examples and notes are clearly marked as such

6. Be consistent with names! Always call the same entity by the same name

7. If you use a TBD (to be determined) or TBR (to be resolved), have a plan. You must state who is responsible for the information, and when will it be completed

8. Make sure your requirement contains all the qualities of a good requirement (see "What makes an SRS a great SRS" above)


Sl id e 14


MedTech


9. Make sure that if a requirement references another document, that it does so correctly References must be listed in applicable document section and state what

part of references applies

List a ll the versions of your document and the changes it applies compared to the previous version

Use a naming convention in order to apply a unique name to every document you use, for example SRS-Proj ID-Version-Date.docx


Sl id e 15


MedTech


10. Make sure that acronyms are used correctly Place the acronym in the acronym list in the specification Spell out the complete phrase followed by the acronym in parenthesis the

first time it is used

The next time, you can just use the acronym

11. Overspecification leads to unfunded requirements and can add duplicate requirements Shorten the requirements as possible


Sl id e 16


MedTech


12. Use the requirement template Define a template document for your requirements This is the structure of a basic requirement:

[Conditions] [Subject][Action][Object][Constraint] Entities: Subject o f the requirements and Object o f the actio n Actio ns: What the subject do es, co ntains an imperative Co nditio ns: What must be in place in o rder fo r the actio n to take place Co nstraints: Qualifies the actio n, perfo rmance

Example: When signal x is received, the system shall set the signal x received bit within 2

seco nds

13. Design for asset reuse14. Finding the right combination of approaches for the development process

X-driven development


Sl id e 17


MedTech

But also

1. Spend time specifying and documenting well software that you plan to keep. 2. Keep documentation to a minimum when the software will only be used for a

short time or has a limited number of users. 3. Have separate individuals write the specifications (not the individual who will

wr ite the code). 4. The person to write the specification should have good communication skills. 5. Take your time with complicated requirements. Vagueness in those areas will

come back to bite you later. 6. Keep the SRS up to date as you make changes. 7. Approximately 20-25% of the project time should be allocated to requirements

definition. 8. Keep 5% of the project time for updating the requirements after the design has

begun. 9. Test the requirements document by using it as the basis for writing the test

plan.


Sl id e 18


MedTech

References


Sl id e 19

Donn Le Vie , Jr, Writing Software Specifications

Michelle Specht, Best Practices Writing Requirements for Requirements Management, https://www.youtube.com/watch?v=vAEbMzNb_nM

Robert Japenga, How to write a software requirements specification

Software Engineering - chp2- requirements specification

Technology

Transcript of Software Engineering - chp2- requirements specification