CEN4033-Ch4-SoftwareRequirements

Software Requirements

Specifications that define what a software system should do, including eliciting, modeling, reviewing, and documenting them for design and testing teams.

Requirement Analyst

A professional responsible for capturing and documenting software requirements in a Software Requirements Specification (SRS) document.

Stakeholders

Individuals or groups with an interest in the software system, including clients, customers, users, domain experts, market researchers, lawyers or auditors, and software engineers.

Functional Requirement

Describes the required behavior in terms of activities, such as how often paychecks are issued.

Quality Requirement

Describes quality characteristics the software must possess, like fast response or ease of use.

Design Constraint

A decision affecting the system's design, such as platform choice.

Process Constraint

A restriction on the techniques or resources that can be used to build the system.

Requirements Definition Documentation

A complete listing of everything the customer wants to achieve.

Requirements Specification Documentation

States the requirements as a specification of how the proposed system shall behave

Characteristics of Requirements

Correct, Consistent, Unambiguous, Complete, Feasible, Testable, Traceable

Use Case

Represents a major required functionality and its variants in a system, helping specify user views of essential behavior.

UML (Unified Modeling Language)

A collection of notations used to document software specifications and designs, including objects, methods, use case diagrams, class diagrams, and more.

Prototype

A model of the proposed system used to elicit feedback, explore options, and determine the feasibility of solutions.

Formal Methods

Mathematically based techniques for specifying and designing software, including functions and relations to model system behavior.

Throwaway Prototyping Approach

A method used to learn more about a problem or proposed solution, not intended to be part of the final software, allowing for quick-and-dirty development.

Evolutionary Prototyping Approach

A prototyping method developed to answer questions and eventually be incorporated into the final product, exhibiting the quality requirements of the end product.

Prototyping

Good for answering questions about the user interfaces

Modelling

Quickly answer questions about constraints on the order in which events should occur, or about the synchronization of activities

Requirements Documentation

The process of outlining the purpose, scope, background, essential characteristics, environment, proposal description, and assumptions related to a system.

Requirements Specification

Detailed documentation of inputs, outputs, data formats, interfaces, functionality, and quality requirements of a system.

IEEE Standard for SRS

Organized document structure including introduction, general product description, specific requirements, and appendices following a set format.

Validation

Process to ensure building the right system. Check that our requirements definition accurately reflects the customer's needs (all stakeholders needs)

Verification

Process to ensure we build the system right. Check that one document or artifact conforms to another.

Measuring Requirements

Involves assessing the size, changes, and understanding of system requirements, often using a rating scheme to evaluate comprehension and design feasibility.

Testers/Designers Profiles

Profiles indicating the understanding and feasibility of system requirements based on a rating scheme, guiding the need for requirement revisions.

Eliciting Requirements

Various sources and techniques used to gather system requirements, leaving solution selection to designers and ensuring accurate reflection of customer expectations.