Guidelines for Writing Quality Requirements

Guidelines for Writing Quality Requirements

Requirements, generally gathered via many different means, will become specifications when they are tightened up and formatted according to the SRS template, or "container". Clarity that can be imbued at this point will be appreciated later. There is not as much precision in the "rules" for requirements as there are for specifications, but the following guidelines will help with the transformation of one to the other:

●  Define the term "requirements" in the context of your project, because it often means different things to different people. Requirements are statements of functionality and quality believed by the stakeholders to be required in the system, but they are not yet "specifications". Requirements may contain high-level functional, behavioral, and informational models (data flow diagrams, entity relationship models, object models, control models), but they are not detailed user interface designs that will be used by developers.

●  Bear in mind that there are different types of requirements (functional, nonfunctional, quality, performance, business, user, constraints, etc.).

●  Address international issues.

●  Identify time-critical functions.

●  Consider safety and security issues.

●  Write requirements that can be traced to specifications (provide the source for specifications' backward trace).

●  Trace software requirements back to system requirements, use cases, or elicitation workshop session documentation.

●  Create a requirements identification scheme (for forward and backward traceability).

●  If meaningful error messages can be determined at this time, document them.

●  Communicate, communicate, communicate. It isn't fair to any stakeholder group for developers to make requirements decisions, particularly not to developers. Often, when an answer is not forthcoming and schedule pressures mount, a developer will attempt to fill the void by making a decision without adequate information and perspective. No "user class" should be left out. Individual product champions may represent user classes, collecting input from the class members.

●  Reduce ambiguity in requirements as early as possible. An ambiguous requirement may have two or more contradictory interpretations or it may be compound, having multiple independent requirement candidates in the same statement. A compound requirement is likely to include the term "and" or "with" - watch for these red flags. An unambiguous requirement will be "primitive" meaning it is clear, concise, and testable. Primitive requirements are cohesive; they represent one and only one thing.

●  Explore the need for derived and conditional requirements. A requirement may be derived, obtained as a necessary or precursor condition for another requirement; or conditional, having other (derived) requirements as necessary or precursory conditions. A function that cannot be implemented until a certain version of an operating system is installed is an example of a conditional requirement. Backward compatibility to other system components is also a conditional requirement.

●  Avoid using intrinsically subjective and ambiguous words when you write requirements. Terms like always, sometimes, often, minimize, maximize, optimize, rapid, quick, user-friendly, easy, simple, normal, usual, large, intuitive, robust, state-of-the-art, improved, efficient, support and flexible are particularly dangerous. Most of these terms are not verifiable.

●  Write test cases against the functional requirements.

●  Consider developing prototypes.

●  Begin a data dictionary.

●  Keep sentences and paragraphs concise, and keep requirements at a consistent level of granularity (one test case's worth of functionality).

●  Avoid redundant requirements.

These guidelines, used along with frequent stakeholder reviews, will provide the proper foundation for the SRS.


srs template, software requirements, prototypes
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus