Doing a Requirement specification is often the most challenging part of project. Even if you are employing Agile development strategies like scrum or xp programming, a proper specification is the base for a project success.

Writing the Requirement specification puts you into the drivingseat of how a specific piece of software might be fleshed out. It allows you to influence and slightly steer the result of a project or specific software feature.

In the Software Industry, SRSs, also known as software functional specifications or system specifications is the basedocument for Software Design, then followed by software implementation.

 4 Goals in creating a Software requirement Specification:

1. The Customer can be sure that his briefing was understood. More exactly, the Customer can be asked if open questions arise. Therefore, the Software Requirement Specification is always written in natural language. It is important to a fluent and well readable tone, in order to speak clarly to all stakeholders
2. Split a Complex Project into manageable Parts. Splitting Software into manageable parts is on of high relevance. Since Software might consist of a big number of moving parts, bits and pieces, organisation, prioitization and background information is key.
3. The Basis for Engineers: A Requirement Document may be used as designbasis for technical engineers. Often people are suprised how many obviouse requirements are overlooked in the designphase. One of the main reasons this can happen is that every person only can cover so many aspects of a project.
4. The Base for Testing and Validation. Since the Project will be finished at some point in time, it is important to know exactly when this point in time is. This point may only be determined by a timeplan and a corresponding requirement specification. Only with this document, all project stakeholders are able to have a common understanding of the current status of a project. When testing and then validating, the usecases, user stories and related information is used for determining the precise success or failrate of a project

 

Inital Information gathering for Software Spec

The very first Phase of a Project is initial Information Gathering. In this Phase, the Author is getting in touch with all stakeholdes, following the key goal of determining the major requirements.

One of the very best strategies is running trough structured Interviews that contain business and organisational questions. It is a reality that people, both specification authors and clients, do have a significant tendency towards predetermining a solution or at least a definite part for getting towards a specific solution.

Mining for unqiue and pure information

• onsite visits, that are documented using Photos and Notes
• questionnaires for Individuals and Groups
• Surveys that are run on the Market or in a Company
• Interviews with key stakeholders
• Business workflow and swot analysis, maybe even leading up to return-on-investment (ROI) analysis and business model calculation
• analysis of client’s current business environment

The perfect Software Requirement Spec

 

Starting a Software requirement Document from scratch: Not the best idea.

Ist not particularly handy nor very smart to start off with a white piece of paper. Using Templates helps the writer and later the reader to understand structure and sense of a Software Requirement Specification Document. Several Standardisation organisations, for example the IEEE Consortium, have identifed a defacto standard for a product, service or software requirement specification.

 

1. Interfaces
2. Functional Capabilities
3. Performance Levels
4. Data Structures/Elements
5. Safety
6. Reliability
7. Security/Privacy
8. Quality
9. Constraints and Limitations

The IEEE Consortium defined these Points as Mission critical

Typically these nine Points now should be transfered into some kind of document index. A Useful form of this template is the following List. Please be aware that there is no „the-best-Template“ or way, but it is rather a set of questions that have to be adressed. The exact set of Questions is different from Author to author.

It is favourable to take a short time aside and analyse several templates that are used for software requirement specification. It is almost impossible to find exactly the perfect specification template that exactly meets your needs. It is usefol to merge and optimize several templates to have awell working tool for your own authorship.

 

Table 1 shows what a basic SRS outline might look like. This example is an adaptation and extension of the IEEE Standard 830-1998:

Table 1 A sample of a basic SRS outline

1. Introduction 1.1 Purpose 1.2 Document conventions 1.3 Intended audience 1.4 Additional information 1.5 Contact information/SRS team members 1.6 References 2. Overall Description 2.1 Product perspective 2.2 Product functions 2.3 User classes and characteristics 2.4 Operating environment 2.5 User environment 2.6 Design/implementation constraints 2.7 Assumptions and dependencies 3. External Interface Requirements 3.1 User interfaces 3.2 Hardware interfaces 3.3 Software interfaces 3.4 Communication protocols and interfaces 4. System Features 4.1 System feature A 4.1.1 Description and priority 4.1.2 Action/result 4.1.3 Functional requirements 4.2 System feature B 5. Other Nonfunctional Requirements 5.1 Performance requirements 5.2 Safety requirements 5.3 Security requirements 5.4 Software quality attributes 5.5 Project documentation 5.6 User documentation 6. Other Requirements Appendix A: Terminology/Glossary/Definitions list Appendix B: To be determined

Table 2 shows a more detailed  software requirements specifications outline, showing the structure of an SRS template.

Table 2 A sample of a more detailed SRS outline

1. Scope	1.1 Identification.Identify the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).1.2 System overview.State the purpose of the system or subsystem to which this document applies.1.3 Document overview.Summarize the purpose and contents of this document.This document comprises six sections: Scope Referenced documents Requirements Qualification provisions Requirements traceability Notes Describe any security or privacy considerations associated with its use.
2. Referenced Documents	2.1 Project documents. Identify the project management system documents here.2.2 Other documents.2.3 Precedence.2.4 Source of documents.
3. Requirements	This section shall be divided into paragraphs to specify the Computer Software Configuration Item (CSCI) requirements, that is, those characteristics of the CSCI that are conditions for its acceptance. CSCI requirements are software requirements generated to satisfy the system requirements allocated to this CSCI. Each requirement shall be assigned a project-unique identifier to support testing and traceability and shall be stated in such a way that an objective test can be defined for it.3.1 Required states and modes.3.2 CSCI capability requirements.3.3 CSCI external interface requirements.3.4 CSCI internal interface requirements.3.5 CSCI internal data requirements.3.6 Adaptation requirements.3.7 Safety requirements.3.8 Security and privacy requirements.3.9 CSCI environment requirements.3.10 Computer resource requirements.3.11 Software quality factors.3.12 Design and implementation constraints.3.13 Personnel requirements.3.14 Training-related requirements. 3.15 Logistics-related requirements. 3.16 Other requirements. 3.17 Packaging requirements. 3.18 Precedence and criticality requirements.
4. Qualification Provisions	To be determined.
5. Requirements Traceability	To be determined.
6. Notes	This section contains information of a general or explanatory nature that may be helpful, but is not mandatory.6.1 Intended use. This Software Requirements specification shall…6.2 Definitions used in this document.Insert here an alphabetic list of definitions and their source if different from the declared sources specified in the “Documentation standard.”6.3 Abbreviations used in this document. Insert here an alphabetic list of the abbreviations and acronyms if not identified in the declared sources specified in the “Documentation Standard.”6.4 Changes from previous issue. Will be “not applicable” for the initial issue.Revisions shall identify the method used to identify changes from the previous issue.

Specification References and Downloads

• “Volere Requirement Specification“
• I Software Specification Template
• Functional Requirement Specification
• Requiremen Spec for an IT Cluster
• Spec definition
• A Functional Specification Article
• Design Spec and also Specs as technical Standards

 

How to write the Perfect SRS Specification with 4 pages		more from user 755994882 on yumpu.com