Software Engineering Chapter 4

Metrics for specifying non-functional requirements: Property - Reliability

- Mean time to failure - Probability of unavailability - Rate of failure occurrence - Availability

Metrics for specifying non-functional requirements: Property - Portability

- Percentage of target dependent statements - Number of target systems

Metrics for specifying non-functional requirements: Property - Speed

- Processed transactions/second - User/event response time - Screen refresh time

Metrics for specifying non-functional requirements: Property - Robustness

- Time to restart after failure - Percentage of events causing failure - Probability of data corruption of failure

Metrics for specifying non-functional requirements: Property - Ease of Use

- Training time - Number of help frames

A scenario may include:

1. A description of what the system and users expect when the scenario starts 2. A description of the normal flow of events in the scenario 3. A description of what can go wrong and how resulting problems can be handled. 4. Information about other activities that might be going on at the same time. 5. A description of the system state when the scenario ends.

Requirements change management

1. Problem analysis and change specification 2. Change analysis and costing 3. Change implementation

Requirements management planning

1. Requirements identification: Each requirement must be uniquely identified so that it can be cross-referenced with other requirements and sued in traceability assessments. 2. A change management process: This is the set of activities that assess the impact and cost of changes. 3. Traceability policies: These policies define the relationships between each requirement and between the requirements and the system design that should be recoded. the traceability policy should also define how these records should by maintained 4. Tool support: Requirements management involves the processing of large amounts of information about the requirements. Tools that may be used range from specialist requirements management systems to shared spreadsheets and simple database systems.

Requirements validation techniques

1. Requirements reviews: The requirements are analyzed systematically by a team of reviews who check for errors and inconsistencies. 2. Prototyping: This involves developing an executable model of a system and using this with end-users and customers to see if it meets their needs and expectations. Stakeholders experiment with the system and feed back requirements changes to the development team. 3. Test-case generation: Requirements should be testable. If the tests for the requirements are devised as part of the validation process, this often reveals requirements problems. If a test is difficult or impossible to design, this usually means that the requirements will be difficult to implement and should be reconsidered. Developing test from the user requirements before any code is written is an integral part of test-driven developments.

Requirements management tool support:

1. Requirements storage 2. Change management 3. Traceability management

Why system requirements should not be concerned with how the system should be designed or implemented:

1. You may have to design an initial architecture of the system to help structure the requirements specification. The system requirements are organized according to the different subsystems that make up the system. 2. In most cases, systems must interoperate with existing systems, which constrain the design and impose requirements on the new system. 3. The use of a specific architecture to satisfy non-functional requirements, such as N-version programming to achieve reliability, may be necessary. An external regulator who needs to certify that the system is safe may specify that an architectural design that has already been certified should be used.

Notations for writing system requirements: Graphical notations

Graphical models, supplemented by text annotations, are used to define the functional requirements for the system. UML (unified modeling language) use case and sequence diagrams are commonly used.

Types of Interviews 2. Open interviews

In which there is no predefined agenda. The requirements engineering team explores a range of issues with system stakeholders and hence develops a better understanding of their needs.

Requirements elicitation and analysis process: Requirements prioritization and negotiation

Inevitably, when multiple stakeholders are involved, requirements will conflict. this activity is concerned with prioritizing requirements and finding and resolving requirements conflicts through negotiations. Usually, stakeholders have to meet to resolve differences and agree on compromise requirements.

Metrics for specifying non-functional requirements: Property - Size

Megabytes/Number of ROM chips

Requirements elicitation and analysis process: Requirements documentation

The requirements are documented and input into the next round of the spiral. An early draft of the software requirements documents may be produced at this stage, or the requirements may simply be maintained informally on whiteboards, wikis, or other shared spaces.

Notations for writing system requirements: Structured natural language

The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.

Notations for writing system requirements: Natural language sentences

The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.

Non-functional requirements

These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process, and constraints imposed by standards. Non-functional requirements often apply to the system as a whole rather than individual system features or services

Functional Requirements

These are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. In some cases, the functional requirements may also explicitly state what the system should not do.

Notations for writing system requirements: Mathematical specifications

These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don't understand a formal specification. They cannot check that it represents what they want, and they are reluctant to accept it as a system contract.

Nonfunctional Requirements - Organizational Requirements

These requirements are brad system requirements derived from policies and procedures in the customer's and developer's organizations. Examples include operational process requirements that define how the system will be used; development process requirements that specify the programming language; the development environment or process standards to be used; and environmental requirements that specify the operating environment of the system.

Nonfunctional Requirements - Product Requirements

These requirements specify or constrain the runtime behavior of the software. Examples include performance requirements for how fast the system must execute and how much memory it requires; reliability requirements that set out the acceptable failure rate; security requirements; and usability requirements

Requirements elicitation and analysis process: Requirements classification and organization

This activity takes the unstructured collection of requirements, groups related requirements and organizes them into coherent clusters.

Nonfunctional Requirements - External Requirements

This broad heading covers all requirements that are derived from factors external to the system and its development process. These may include regulatory requirements that set out what must be done for the system to be approved for use by a regulator, such as a nuclear safety authority; legislative requirements that must be followed to ensure that the system operates within the law; and ethical requirements that ensure that the system will be acceptable to its users and the general public.

Requirements elicitation and analysis process: Requirements of discovery and understanding

This is the process of interacting with stakeholders of the system to discover their requirements. domain requirements from stakeholders and documentation are also discovered during this activity.

Types of Interviews: 1. Closed interviews

Where the stakeholder answers a predefined set of questions

Two fundamental approaches to elicitation: 1. Interviewing

Where you talk to people about what they do

Two fundamental approaches to elicitation: 2. Observation or ethnography

Where you watch people doing their job to see what artifacts they use, how they use them, and so on.