The chapter discusses documenting software requirements specifications, including the purpose and structure of SRS documents. It covers why requirements are documented, what an SRS contains, a common SRS template, and how requirements specification differs for agile projects.
The chapter discusses documenting software requirements specifications, including the purpose and structure of SRS documents. It covers why requirements are documented, what an SRS contains, a common SRS template, and how requirements specification differs for agile projects.
• This chapter addresses the purpose, structure, and
contents of the SRS (Software Requirement Specification) • After finish this chapter, student should understand the purpose, structure of the SRS. • Student could understand what they do and what they have to write in every section of the SRS document. • Student could enhance the difference in SRS document between Agile projects and other projects Contents
1. Why is documenting the requirements?
2. The software requirements specification 3. A software requirements specification template 4. Requirements specification on agile projects Why is documenting the requirements? • The result of requirements development is a documented agreement among stakeholders about the product to be built. • The product’s functional and nonfunctional requirements often are stored in a software requirements specification, or SRS, which is delivered to those who must design, build, and verify the solution. • You can represent software requirements in several ways, including: – Well-structured and carefully written natural language. – Visual models that illustrate transformational processes, system states and changes between them, data relationships, logic flows, and the like. – Formal specifications that define requirements by using mathematically precise specification languages. The software requirements specification • It is sometimes called a business requirements document (BRD), functional specification, product specification, system specification, or simply requirements document. • Audiences rely on the SRS: Customers, Project managers , Software development teams , Testers, Maintenance and support staff, Documentation writers , Training personnel , Legal staff , Subcontractors The software requirements specification • How many specifications? • How to organize and write SRS (detail in page 185) • Purpose, how to do? – Labeling requirements – Sequence number – Hierarchical numbering – Hierarchical textual tags • Dealing with incompleteness • User interfaces and the SRS A software requirements specification template Requirements specification on agile projects • The extent to which just-in-time informal verbal and visual communication between customers and developers can supply the necessary details to permit the correct implementation of each user requirement • The extent to which informal communication methods can keep the team effectively synchronized across time and space • The extent to which it is valuable or necessary to retain requirements knowledge for future enhancement, maintenance, application reengineering, verification, statutory and audit mandates, product certification, or contractual satisfaction • The extent to which acceptance tests can serve as effective replacements for descriptions of the expected system capabilities and behaviors • The extent to which human memories can replace written representations