Good Practices for Requirements Engineering (2)

Requirements Analysis :

●        Requirements analysis involves refining the requirements to ensure that all stakeholders understand them and scrutinizing them for errors, omissions, and other deficiencies.

●        Analysis includes decomposing high-level requirements into details, building prototypes, evaluating feasibility, and negotiating priorities.

●        The goal is to develop requirements of sufficient quality and detail that managers can construct realistic project estimates and technical staff can proceed with design, construction, and testing.

●        It is helpful to represent some of the requirements in multiple ways—for example, in both textual and graphical forms.

●        Multiple views also help all stakeholders arrive at a common understanding—a shared vision—of what they will have when the product is delivered.

Good practices for requirements analysis and representation  include:

●        Draw a context diagram.

§  It shows how the new system fits into its environment. It defines the boundaries and interfaces between the system being developed and the entities external to the system, such as users, hardware devices, and other information systems.

●        Create user interface and technical prototypes.

§  Constructed and used when developers or users aren't certain about the requirements.

●        Analyze requirement feasibility. 

§  Evaluate the feasibility of implementing each requirement at acceptable cost and performance in the intended operating environment. Understand the risks associated with implementing each requirement, including conflicts with other requirements, dependencies on external factors, and technical obstacles.

●        Prioritize the requirements.

§  Apply an analytical approach to determine the relative implementation priority of product features, use cases, or individual requirements. Evaluate and adjust priorities periodically throughout the project as customer needs, market conditions, and business goals evolve.

●        Model the requirements.

§  A graphical analysis model depicts requirements at a high level of abstraction. Models can reveal incorrect, inconsistent, missing, and superfluous requirements. Such models include data flow diagrams, entity-relationship diagrams, state-transition diagrams or statecharts, dialog maps, class diagrams, sequence diagrams, interaction diagrams, decision tables, and decision trees.

●        Create a data dictionary.

§  Definitions of all the data items and structures associated with the system reside in the data dictionary. This enables everyone working on the project to use consistent data definitions. The data dictionary  facilitates communication between the customers and the development team.

●        Allocate requirements to subsystems.

§  The requirements for a complex product that contains multiple subsystems must be apportioned among the various software, hardware, and human subsystems and components.

●        Apply Quality Function Deployment (QFD).

§  It provides an analytical way to identify those features that will provide the greatest customer satisfaction. QFD addresses three classes of requirements: expected requirements, where the customer might not even state them but will be upset if they are missing; normal requirements; and exciting requirements, which provide high benefit to customers if present but little penalty if not.

Requirements Specification

●        The business requirements is recorded in a vision and scope document.

●        The user requirements typically are represented in the form of use cases or as event-response tables.

●        The Software Requirements Specification (SRS) contains the detailed software functional and nonfunctional requirements.

       Good practices for requirements specification include:

●        Adopt an SRS template.

●        Define a standard template for documenting software requirements in your organization. The template provides a consistent structure for recording the functionality descriptions and other requirements-related information. Example of SRS template is IEEE Standard 830.

●        Identify sources of requirements.

●        Trace each requirement back to its origin (source). This might be a use case or some other customer input, a high-level system requirement, a business rule, or some other external source. Recording the stakeholders who are materially affected by each requirement tells you whom to contact when a change request comes in.

●        Uniquely label each requirement.

●        Define a convention for giving each requirement in the SRS a unique identifying label. Labeling the requirements permits requirements traceability and the recording of changes made.

●        Record business rules.

●        Document your business rules separately from the SRS because they typically have an existence beyond the scope of a specific project. Some business rules will lead to functional requirements that enforce them, so define traceability links between those requirements and the corresponding rules.

●        Specify quality attributes. 

●        These include performance, efficiency, reliability, usability, and many others. Document the quality requirements in the SRS. Customer input on the relative importance of these quality attributes lets the developer make appropriate design decisions.

Requirements Validation

●        Validation ensures that the requirement statements are correct, demonstrate the desired quality characteristics, and will satisfy customer needs.

●        Writing test cases from the requirements often reveals ambiguities and vagueness.

       Good practices for requirements validation include:

●        Inspect requirements documents.

●        Formal inspection (by small team) of requirements documents is one of the highest-value software quality practices available. Informal preliminary reviews during requirements development are also valuable.

●        Test the requirements.

●        Derive functional test cases from the user requirements to document the expected behavior of the product under specified conditions. Walk through the test cases with customers to ensure that they reflect the desired system behavior. Trace the test cases to the functional requirements to make sure that no requirements have been overlooked and that all have corresponding test cases. Use the test cases to verify the correctness of analysis models and prototypes.

●        Define acceptance criteria. 

●        Ask users to describe how they will determine whether the product meets their needs and is fit for use. Base acceptance tests on usage scenarios.