Requirements as an Input

Requirements are a critical input to project acquisition and/or software and system development. The requirements are the starting point for system design. The requirements are an important input to software and hardware (if applicable) test plans. In addition, the requirements provide the customer a basis for formal user testing and acceptance of the system.

Requirements Phase Deliverables and Artifacts include:

a) The Final Requirements document

b) Requirements Presentations

c) Meeting Minutes recording decisions

d) Design, Development, and Implementation Work Plan (note: the Work Plan should be baselined when the requirements are final)

e) Requirement Quality Assurance checklist

f) Requirements Signoff Report

g) Populated Requirement Traceability Matrix (RTM)

h) Policy Letters, Regulations, other legal mandate document

i) Written Policy Clarifications (if applicable)

Appendices

Appendix A: Acronyms & Abbreviations

Appendix B: Requirements Checklist – Sample

General Requirement Document

· Is a functional overview of the system provided?

· Have the software and hardware environments been specified?

· Are implementation assumptions stated?

· Have the functionality of hardware or software interacting with the system been properly specified?

· Has every acronym been defined?

· Is each requirement traceable to its source? Employ a numbering scheme to facilitate traceability and control.

· Are relationships among requirements clearly defined and organized to show how they may relate to form subsystems and a complete system?

· Are boundaries, scope, and context of the requirements identified?

· Is the document easily searchable for modification, and addition of requirements?

· Do the requirements avoid specifying design?

· Are the requirements at a fairly consistent level of detail?

· Are the requirements clear enough to be turned over to an independent group for implementation and still be understood?

· Does the set of requirements adequately address all appropriate exception conditions?

· Can the requirements be implemented within known constraints?

· Are all cross-references to other requirements correct?

· Are all missing items or unresolved issues identified with a TBD, an owner, and a time-line for closing it?

·

Business and Functional Requirements

· Are the high-level business objectives described?

· Are the requirements understandable by all stakeholders?

· Is the value to the business identified? (Cost savings, reduced inventory, etc.)

· Is the value to the customer identified? (New features, improved usability, etc.)

· Does this requirement answer the question ‘Why is this needed’?

· Does the set of functional requirements meet the needs outlined by business requirements? (e.g. complete, sufficient, etc.)

· Is the relation between functional and the non-functional requirements clear?

Interface Requirements

· Are all inputs to the system specified, including their source, accuracy, range of values, parameters and frequency?

· Are all outputs from the system specified, including their destination, accuracy, range of values, parameters and format?

· Are all screen formats specified?

· Are all report formats specified?

· Are all interface requirements between hardware, software, personnel, and procedures included?

· Are all communication interfaces specified, including handshaking, error-checking, and communication protocols?

Technical Requirements

· Are all inputs to a function sufficient to perform the required function?

· Are undesired events/inputs considered and their required responses specified?

· Have the types, initial values, units been defined for every object attribute?

· Have the parameter and return types of all object operations been defined?

· Have the accuracy, precision, range, type, rate, units, frequency of inputs and outputs been specified for each function?

· Is the expected response time, from the user's point of view, specified for all operations?

· Is the level of security specified?

· Is the reliability specified, including the consequences of software failure, the vital information that needs to be protected from failure, and the strategy for error detection and recovery?

· Is the maximum memory specified?

· Is the maximum storage specified?

Individual Requirements

· Is the requirement clear and concise?

· Is the requirement stated in as simple a form as possible?

· Is the requirement testable/verifiable?

· Is the requirement correct?

· Is the requirement in scope? (i.e., the system will be considered incomplete if even one requirement is left out)

· Is the requirement as modifiable as possible?

· Is the requirement written in the customer’s language, using the customer’s terminology?

· Is the requirement necessary?

· Does this requirement answer the question ‘How Well’?

· Is each requirement implementation independent?

System Requirements:

· Reliability

o Are the reliability (MTBF) requirements specified?

o Are the availability (up time) requirements specified?

o Are the serviceability (MTTR) requirements specified?

o Are the robustness requirements specified?

· Performance

o Are the response time or latency requirements specified?

o Are the throughput requirements specified?

o Are the data volume requirements specified? (input, stored, output)

o Are the peak or short-term load requirements specified?

· Safety/Security

o Are the security requirements specified?

o Are the safety requirements specified?

· Configuration

o Are the supported configurations specified?

o Are the compatibility requirements specified? (backwards, other applications, etc.)

· Usability

o Are the usability requirements specified?

o Are the internationalization/localization requirements specified?

o Are the look and feel requirements specified? (e.g. color schemes, standards, etc.)

· Operational

o Are all operational constraints or requirements specified? (e.g. network limitations, memory limitations, processor speed)

Sources:

Karl Weigers, “Writing Quality Requirements”, Software Development Magazine (May 1999), Software Requirements Specification Checklist (also found in www.fox.wikis.com

www.construx.com – Requirement Toolbox Tool)

Date: 2015-02-16; view: 746