Introductiony Software engineering projects, as defined by the IEEE/EIA, consist of a number of y y y y y

development activities Each activity is characterized by a set of deliverables, normally in the form of code or documentation. Providing a structured template for software documentation assists both the customers and developers as well as the assessment aspects of a software engineering project. These templates provide a guide to the expected format and content of the documentation deliverables based on international standards. This presentation does not provide specific assessment criteria: it describes the development documentation. Also, it does not cover the product documentation (user manual, reference manual, installation manual, or internal documentation).

Contd..y The minimal document set, and the content of each document, has been

derived from the full IEEE set of software engineering documents.y The templates described here are based on the most recent IEEE

standards and US MIL-STD-498

Various System DocumentationsVarious types of Documentation used Software Project Management Plan (SPMP) Software Requirements Specifications (SRS) Description Description of the software approach and associated milestones. Description of the expected software features, constraints, interfaces and other attributes. Description of how the software will meet the requirements. Also describes the rationale for design decisions taken. Description of the plan and specifications to verify and validate the software and the results.

Software Design Description (SDD)

Software Test Documentation (STD)

Purpose of each documentTypes of Documentation Software Project Management Plan (SPMP) Summary of Purpose To document the agreed deliverables and dates.

Software Requirements Specifications (SRS)

To document the agreed requirements with the project supervisor; to provide the basis for design; to provide the basis for system test. To document the design and design decisions in order to provide the basis for implementation and unit test To document how the software will be tested, and record the results.

Software Design Description (SDD)

Software Test Documentation (STD)

Common Sections for the Documentation Set.y Each document within the recommended set has some common

characteristics. The following pages are included in each document: y I. Cover page (contents & layout)

Contd..y II. Additional Material (contents) y ADDITIONAL ISSUES y DEFINITIONS, ACRONYMS, AND ABBREVIATIONS y REFERENCES y APPENDICES

Contents of the Documentation Set.

Contd..

Contd..

Contd..

Requirements Analysis and Requirements Specification

Requirements EngineeringRequirements Engineering Requirements Elicitation

Requirements Analysis Requirements Verification

Requirements Specification Requirements Management

Requirements Analysis and Specification definitionsy Requirements Analysis is the process of understanding

the customer needs and expectations from a proposed system or application and is a well-defined stage in the Software Development Life Cycle model. y Requirements are a description of how a system should behave or a description of system properties or attributes. It can alternatively be a statement of what an application is expected to do.

What vs. HowUser Needs System Requirements System Design Software Requirements Software Design

3 DilemmaWhat How What How What How What How

Requirements vs. DesignRequirements Describe what will be delivered Primary goal of analysis: UNDERSTANDING There is more than one solution Customer interested Design Describe how it will be done Primary goal of design: OPTIMIZATION There is only one (final) solution Customer not interested (Most of the time) except for external

Requirement Specificationy Requirements Specification y A document that clearly and precisely describes, each of the essential requirements of the software and the external interfaces.y

(functions, performance, design constraint, and quality attributes)

y Each requirement is defined in such a way that its

achievement is capable of being objectively verified by a prescribed method; for example inspection, demonstration, analysis, or test

Contd..y Requirements, once elicited, modeled and analyzed should be documented in clear, unambiguous terms. y A written requirements document is critical so that its circulation is possible among all stakeholders including the client, user-groups, the development and testing teams. y Current requirements engineering practices reveal that a well-designed, clearly documented Requirements Specification is vital and serves as a: y Base for validating the stated requirements and resolving stakeholder conflicts, if any y Contract between the client and development team y Basis for systems design for the development team y Bench-mark for project managers for planning project development lifecycle and goals y Source for formulating test plans for QA and testing teams y Resource for requirements management and requirements tracing y Basis for evolving requirements over the project life span

Contd..y The software requirements specification is a document that lists out stakeholders

needs and communicates these to the technical community that will design and build the system. y The challenge of a well-written requirements specification is to clearly communicate to both these groups and all the sub-groups within. y To overcome this, Requirements Specifications may be documented separately as y User Requirements - written in clear, precise language with plain text and use cases, for the benefit of the customer and end-user y System Requirements - expressed as a programming or mathematical model, addressing the Application Development Team and QA and Testing Team. y Requirements Specification serves as a starting point for software, hardware and database design. It describes the functions of the system, performance of the system and the operational and user-interface constraints that will govern system development.

Requirement Specification and Analysis

User Requirement Specification (USR)

Software Requirement Specification (SRS)

The requirements documenty The requirements document is the official statement of what is

required of the system developers. y Should include both a definition of user requirements and a specification of the system requirements. y It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it

Users of a requirements document

IEEE Standards for Various DocumentationsIEEE Standard IEEE 830-1998 IEEE 730 IEEE 828 IEEE 829 IEEE 830 IEEE 1012 IEEE 1016 IEEE 1058 Description Specification of software requirements SQAP - Software Quality Assurance Plan S P - Software onfi uration ana ement Plan

STD - Software Test Documentation SRS - Software Requirements Specification SVVP - Software Validation & Verification Plan SDD - Software Desi n Description SP P - Software Project ana ement Plan

IEEE requirements standardy Defines a generic structure for a requirements document that must be

instantiated for each specific system.y Introduction. y General description. y Specific requirements. y Appendices. y Index.

Requirements document structurey y y y y y y y y y

Preface Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index

Key pointsy Requirements set out what the system should do and define

constraints on its operation and implementation. y Functional requirements set out services the system should provide. y Non-functional requirements constrain the system being developed or the development process. y User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams.

Key pointsy System requirements are intended to communicate the functions

that the system should provide. y A software requirements document is an agreed statement of the system requirements. y The IEEE standard is a useful starting point for defining more detailed specific requirements standards.

Difference Between URS and SRSy SRS is system requirement specification which usually

contains functional requirements. URS is user requirement specification which contains business requirements.y URS document is drafted by the clients (end users) in their

own language. This URS document is converted into SRS document by the system analysts of s/w development company in the language understandable by their team

Exampley A bank wants to computerize their bank branches. They approach a s/w development company with a URS. y One of the requirements defined by the end users in URS is to calculate new balance each time customer deposits or withdraws money in his/her bank a/c. So, the new balance will be equal to old balance plus total deposits, less total withdrawals.

Now, the system analysts look into this and define the same point as, Balance = Balance + TotalDeposit Balance = Balance TotalWithdrawals

User Requirement Specification (URS)y User Requirements

Specifications (URS) are prepared for each critical utility or piece of equipment prior to the manufacturing stage.

y The specification provides a list of requirements for

the planned system. The User Requirements Specification specifies the needs of the end user as well as any regulatory requirements.

Contd

y The document is provided to the supplier in order to ensure

that all expected requirements, of the end user, for the utility or piece of equipment have been specified and supplied prior to the actual manufacturing stage.y These specifications will be the basis for the Functional

Requirements Specification and the Hardware and Software Specifications that detail the design of the utility or piece of equipment.

Contd..

y A good set of user requirements are needed for any project,

especially computer system projects, to be successful.y This is where many projects fail, in that they do not specify

correctly what the system should do.y In fact many systems have just been given a deadline for

delivery, a budget to spend, and a notion of what it should do.

Guidelines for URS1. Each requirement must be uniquely referenced, although not mandatory, attempts at this stage should be made to keep each requirement to less than 200 words. 2. Requirement statements should not be duplicated or contradicted. 3. The URS should express requirements and not design solutions. 4. Each requirement should be testable.

Contd.. 5. The user requirement specifications must be understood by both the customer and supplier; ambiguity and jargon must be avoided. 6. Whenever possible, the user requirement specifications must distinguish between regulatory requirements and desirable features, by using should to represent a nice to have function, and must to indicate a mandatory function. 7. There should be a formal review of the URS between the customer and supplier to ensure that requirements are understood.

URS SCOPEy User

Requirements Specification (URS) Scope includes but is not limited to; * Level-1, full details of end user operability. * Level-2, full details of functionality. * Level-3, software functionality interface. * A full description of the required system performance. * Performance criteria, critical parameters and operating range. * Cleaning and maintenance requirements. * Appropriate regulatory requirements. * Documentation requirements. * Training requirements. * Industry standard testing may be required.

Software Requirement Specifications (SRS)y A Software Requirements Specification (SRS) -

a requirements specification for a software system - is a complete description of the behavior of a system to be developed.y It establishes the basis for agreement between customers

and contractors or suppliers on what the software product is expected to do, as well as what it is not expected to do.

Features of SRSy Some of the features of SRS are -

It sets permits a rigorous assessment of requirements before design can begin. It sets the basis for software design, test, deployment, training etc. It also sets pre-requisite for a good design though it is not enough. It sets basis for software enhancement and maintenance. It sets Basis for Project plans like Scheduling and Estimation.

Benefits of a Great SRSy The IEEE 830 standard defines the benefits of a good SRS: y Establish the basis for agreement between the customers and the suppliers on

what the software product is to do. The complete description of the functions to be performed by the software specified in the SRS will assist the potential users to determine if the software specified meets their needs or how the software must be modified to meet their needs. y Reduce the development effort. The preparation of the SRS forces the various concerned groups in the customers organization to consider rigorously all of the requirements before design begins and reduces later redesign, recoding, and retesting. Careful review of the requirements in the SRS can reveal omissions, misunderstandings, and inconsistencies early in the development cycle when these problems are easier to correct. y Provide a basis for estimating costs and schedules. The description of the product to be developed as given in the SRS is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates.

Contd..y Provide a baseline for validation and verification. Organizations can develop their validation and Verification plans much more productively from a good SRS. As a part of the development contract, the SRS provides a baseline against which compliance can be measured. y Facilitate transfer. The SRS makes it easier to transfer the software product to new users or new machines. Customers thus find it easier to transfer the software to other parts of their organization, and suppliers find it easier to transfer it to new customers. y Serve as a basis for enhancement. Because the SRS discusses the product but not the project that developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS may need to be altered, but it does provide a foundation for continued production evaluation.

What should SRS Address ?y From the IEEE 830 standard: y The basic issues that the SRS writer(s) shall address are the following: y a) Functionality. What is the software supposed to do? y b) External interfaces. How does the software interact with people, thesystems hardware, other hardware, and other software? y c) Performance. What is the speed, availability, response time, recovery time of various software functions, etc.? y d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations? y e) Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?

Characteristics of a great SRSy From the IEEE 830 standard:

y An SRS should be y a) Correct y b) Unambiguous y c) Complete y d) Consistent y e) Ranked for importance and/or stability y f) Verifiable y g) Modifiable y h) Traceable

Contd..y Correct - The specifications prepared is to be correct. No one writes a specification that they know is incorrect. We like to say - "Correct and Ever Correcting." The discipline is keeping the specification up to date when you find things that are not correct. y Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. Again, easier said than done. Spending time on this area prior to releasing the SRS can be a waste of time. But as you find ambiguities - fix them. y Complete - A simple judge of this is that is should be all that is needed by the software designers to create the software. y Consistent - The SRS should be consistent within itself and consistent to its reference documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another.

Contd..y Ranked for Importance - Very often a new system has requirements that are really marketing wish lists. Some may not be achievable. It is useful provide this information in the SRS. y Verifiable - Don't put in requirements like - "It should provide the user a fast response." Another of my favorites is - "The system should never crash." Instead, provide a quantitative requirement like: "Every key stroke should provide a user response within 100 milliseconds." y Modifiable - Having the same requirement in more than one place may not be wrong - but tends to make the document not maintainable. y Traceable - Often, this is not important in a non-politicized environment. Why do we need this requirement?

Requirements Analysis Issuesy Stakeholder issues y Users do not understand what they want or users don't have a clear idea of their requirements y Users will not commit to a set of written requirements y Users insist on new requirements after the cost and schedule have been fixed y Communication with users is slow y Users often do not participate in reviews or are incapable of doing so y Users are technically unsophisticated y Users do not understand the development process y Users do not know about present technology y This may lead to the situation where user requirements keep changing even when system or product development has been started.

Contd..y Engineer/developer issues y Possible problems caused by engineers and developers during

requirements analysis are:y Technical personnel and end-users may have different vocabularies.

Consequently, they may wrongly believe they are in perfect agreement until the finished product is supplied. y Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client. y Analysis may often be carried out by engineers or programmers, rather than personnel with the people skills and the domain knowledge to understand a client's needs properly.