Requirements and Stories
The software requirements specification document should contain a written definition of the software functions. It is not possible to validate software - in the sense of FDA approach - without predetermined and documented software requirements. Typical software requirements specify the following:
- All functions that the software system will perform
- All software system inputs and outputs
- The definition of all external and user interfaces as well as any internal software to system interfaces
- How users will interact with the system
- What constitutes an error and how errors should be handled
- All ranges, limits, defaults, and specific values that the software will accept
- All performance requirements that the software will (e.g. data throughput, reliability, response time, and timing)
- The intended operation environment for the software, if this is a design constraint (e.g. hardware platform, operating system)
- All safety related requirements, specifications, features, or functions that will be implemented in software
The above documentation is written for traceability and validation purposes. How can we connect them with the stories of Scrum?
In fact the solution is straight forward. The team works following the Scrum approach. For each story we identified the set of involved requirements and add them to the comment field of the story. Therefore the Scrum team works with stories, tasks, product and iteration backlogs. Once a story is done the associated requirements are potentially implemented and can be traced to the release at the end of the sprint. Regular tools are used to generate the traceability and risks matrix as requested by FDA or CE product responsibility.
Ideally the document has a hierarchical structure of features, epics, stories, software requirements. People working last millennium with RUP would say features, key mechanisms, use cases, software requirements.
The major change being that stories describe one flow of control without exceptional conditions. Another tremendous change is that stories have acceptance criteria. These acceptance criteria should be automatically tested using a behavior driven development approach - BDD
-. So we have reach the grail of all system engineers: BDD tests are in fact executable requirements guarantying that the system implements the specified requirements.
FDA clearly allows existence of incomplete or conflicting requirements. The quality system regulation requires a mechanism for addressing incomplete, ambiguous, or conflicting requirements.
The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to his general discussion or the specific technology domain being addressed. However, the following characteristics are generally acknowledged.
| Characteristic|| Explanation|| Comment|
| Cohesive|| The requirement addresses one and only one thing|| |
| Complete|| The requirement is fully stated in one place with no missing information|| |
| Consistent|| The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation|| |
| Correct|| The requirement meets all or part of a business need as authoritatively stated by stakeholders|| |
| Current|| The requirement has not been made obsolete by the passage of time|| |
| Externally Observable|| The requirement specifies a characteristic of the product that is
externally observable or experienced by the user. "Requirements" that
specify internal architecture, design, implementation, or testing
decisions are properly constraints, and should be clearly articulated
in the Constraints section of the Requirements document.|| |
| Feasible|| The requirement can be implemented within the constraints of the project|| |
| Unambiguous|| The requirement is concisely stated without recourse to technical
jargon, acronyms (unless defined elsewhere in the Requirements
document), or other esoteric verbiage. It expresses objective facts,
not subjective opinions. It is subject to one and only one
interpretation. Vague subjects, adjectives, prepositions, verbs and
subjective phrases are avoided. Negative statements and compound
statements are prohibited.|| |
| Mandatory|| The requirement represents a stakeholder-defined characteristic the
absence of which will result in a deficiency that cannot be ameliorated.|| |
| Verifiable|| The implementation of the requirement can be determined through one of
four possible methods: inspection, analysis, demonstration, or test.|| |
A standard classification of requirements is FURPS
. FURPS is an acronym representing a model for classifying software quality attributes (requirements
- Functionality - Feature set, Capabilities, Generality, Security
- Usability - Human factors, Aesthetics, Consistency, Documentation
- Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure
- Performance - Speed, Efficiency, Resource consumption, Throughput, Response time
- Supportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability
The "+" in FURPS+ also helps us to remember concerns such as:
- A design requirement, often called a design constraint, specifies or constrains the options for designing a system. For example, if you specify that a relational database is required, that's a design constraint.
- An implementation requirement specifies or constrains the coding or construction of a system. Examples might include required standards, implementation languages, and resource limits.
- An interface requirement specifies an external item with which a system must interact, or constraints on formats or other factors used within such an interaction.
- A physical requirement specifies a physical constraint imposed on the hardware used to house the system — shape, size, or weight, for example.
A example of checklist can be found here
The attentive reader has already find out that requirements specifying details of a story and defining automatic testable acceptance criteria always fulfill the above criteria.
In the mid-1980s, prototyping was seen as the solution to the requirements analysis problem. Prototypes are mock-ups of an application. Mock-ups allow users to visualize an application that hasn't yet been constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably.
However, over the next decade, while proving a useful technique, prototyping did not solve the requirements problem:
- Managers, once they see a prototype, may have a hard time understanding that the finished design will not be produced for some time.
- Designers often feel compelled to use patched together prototype code in the real system, because they are afraid to 'waste time' starting again.
- Prototypes principally help with design decisions and user interface design. However, they can't tell you what the requirements originally were.
- Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process.
- Prototypes work well for user interfaces, screen layout and screen flow but are not so useful for batch or asynchronous processes which may involve complex database updates and/or calculations.
Prototypes can be flat diagrams (referred to as 'wireframes') or working applications using synthesized functionality. Wire frames are made in a variety of graphic design documents, and often remove all color from the software design (i.e. use a greyscale color palette) in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion over the final visual look and feel of the application.