Requirements Specifications and Requirements Attributes R. Kuehl/J. Scott Hawker p. 1 R I T Software Engineering
Topics Documenting Requirements The Software Requirements Specification Guidelines for writing requirements Requirements Attributes Requirements Fit Criteria Assertion: Even if you do not write a formal SRS, it is important to form good requirement “statements” in whatever representation is used “What we have here is a failure to communicate!” R. Kuehl/J. Scott Hawker p. 2 R I T Software Engineering
Types of Requirements Business Requirements Business Rules Vision and Scope Document Quality Attributes User Requirements User Requirements Document External Interfaces System Functional Constraints Requirements Requirements Software Requirements Specification Solid arrow – stored in Dotted arrow – origin of or influence R. Kuehl/J. Scott Hawker p. 3 R I T Software Engineering
Software Requirements Specification (SRS) Capture all requirements Cornerstone document for stakeholder communications A “contract”, a baseline for managing change If it is not in the SRS Package, don’t work on it! If it is in the SRS Package, you are accountable to deliver that functionality and quality! Do these rules apply to an agile project? R. Kuehl/J. Scott Hawker p. 4 R I T Software Engineering
Characteristics of a Well-Constructed SRS Correct, complete, consistent, unambiguous Validated and testable Well stated – active voice from the user or system perspective [with conditions ]<system/user> “shall” <action verb> <observable result>[ meet quality objective] “When no contractor is available in the customer’s postal code, the system shall allow the scheduler to select from a list of nearby postal codes.” Well written – grammar (“shall” means mandatory), spelling, vocabulary, complete sentences R. Kuehl/J. Scott Hawker p. 5 R I T Software Engineering
Characteristics of a Well-Constructed SRS-2 Essential requirements – don’t bias solution design Logically organized – e.g., by use case Labeled for reference and traceability Identify assumptions and unknowns TBD (defined) TBV (validated) How much detail ? Func ( customer involvement, developer experience, development locality, business context) R. Kuehl/J. Scott Hawker p. 6 R I T Software Engineering
Characteristics of a Well-Constructed SRS-3 Use diagrams and tables Add a glossary, data dictionary R. Kuehl/J. Scott Hawker p. 7 R I T Software Engineering
A Requirement Example 4.2.2 (High) The ICS shall provide for a class instructor (or a designated representative) to enter or change grades for students in the class, for a designated grading element. [4.2.2.1 The ICS shall display a list of grading elements for the class. 4.2.2.2 When the instructor selects a grading element, the ICS shall display a list of students, each with a field for entering or changing a grade. 4.2.2.3 After the instructor enters or changes grades and submits them, the ICS shall store the grades in the student records. 4.2.2.4 After submission of grades, the ICS shall display the grade records, for all students in the class.] R. Kuehl/J. Scott Hawker p. 8 R I T Software Engineering
Requirements Attributes Information associated with a requirement that links the requirement to other project elements to facilitate development processes Attribute examples: Priority Status Stability Value Cost Risk Release R. Kuehl/J. Scott Hawker p. 9 R I T Software Engineering
Informal Priority Metric High Software not acceptable unless (essential) provided in the manner agreed, in the coming release. Medium Desirable, but the product would (conditional) not be unacceptable if absent in the coming release. Low Nice to have someday, if (optional) resources permit. • Help balance scope – budget, schedule, risk, cost, quality • Manage customer expectations, negotiate R. Kuehl/J. Scott Hawker p. 10 R I T Software Engineering
Requirements Status Proposed Based on elicitation and analysis, a software requirement is incorporated in the initial draft of the SRS. Approved Stakeholders have reviewed the requirement and given approval for its inclusion in the SRS. Validated The requirement has been reviewed as part of a formal inspection process, test scenarios have been developed that test the requirement, appropriate changes have been made to the requirement, and key stakeholders have signed off on the SRS containing the requirement. A good project management metric R. Kuehl/J. Scott Hawker p. 11 R I T Software Engineering
Requirements Fit Criteria “Fit” – the solution completely satisfies the requirement Quantify behavior, performance, or some other quality of the requirement For functional and non-functional requirements Quality attributes have architecture design implications Measurable and testable If you can’t measure a requirement, then is it really a requirement? R. Kuehl/J. Scott Hawker p. 12 R I T Software Engineering
Functional Example Description: The product shall record the weather station readings Fit criteria: The recorded weather station readings shall match the readings sent by the weather station Description: The ATM shall dispense cash after the withdrawal transaction is approved. Fit criteria: ? R. Kuehl/J. Scott Hawker p. 13 R I T Software Engineering
Non-Functional Fit Criteria – Usability Example Description: The product shall be user friendly Fit criterion: New users shall be able to add, change, and delete information within 30 minutes of their first attempt at using the product Fit criterion: Within three months of introducing the product, 60% of the users shall be using it to carry out the agreed work. From those users, the product shall receive a 75% approval rating R. Kuehl/J. Scott Hawker p. 14 R I T Software Engineering
Shall, must, will, should, may, and can Shall is used to indicate mandatory requirements for conformance to the specification with no deviation ( shall equals is required to ). Must shall not be used when stating mandatory requirements; must is used only to describe unavoidable situations. Will shall not be used when stating mandatory requirements; will is only used in statements of fact. Should is used to indicate that among several possibilities one is recommended as particularly suitable, without excluding others; or a certain course of action is preferred but not required; or a certain course of action is deprecated but not prohibited ( should equals is recommended that ). May is used to indicate a permissible course of action within the limits of the specification ( may equals is permitted to ). Can is used for statements of possibility and capability, whether material, physical, or causal ( can equals is able to ). 2007 version of the IEEE Standards Style Manual section 13.1 http://standards.ieee.org/guides/style/ R. Kuehl/J. Scott Hawker p. 15 R I T Software Engineering
Recommend
More recommend
