Requirements Engineering

Requirements Engineering Overview

• Requirements engineering involves determining the services a customer needs from a system and its operating constraints.
• System requirements are descriptions of system services and constraints created during the requirements engineering process.

Defining Requirements

• Requirements can be high-level abstract statements or detailed functional specifications.
• Requirements serve a dual function, providing a broad basis for contract bids and a specific foundation for the contract itself.

Requirements Abstraction

• When contracting a software development project, a company needs to define needs abstractly to allow solution flexibility.
• Contractors bid with different approaches.
• The contractor must provide a detailed system definition after a contract award for client understanding and validation.
• Both abstract needs and the detailed system definition are requirements documents.

Requirement Types

• User requirements are natural language statements and diagrams describing system services and constraints, and are intended for customers.
• System requirements are structured documents with detailed descriptions of system functions, services, and operational constraints, and may be part of a client-contractor agreement.

System Stakeholders

• Stakeholders include anyone affected by the system, who may also have a legitimate interest in it.
• Stakeholder types include end users, system managers, system owners, and external stakeholders.

Agile Methods and Requirements

• Agile methods suggest that detailed system requirements are a waste of time because they change quickly.
• Agile methods use incremental requirements engineering, and may express requirements as user stories.
• Agile methods are practical for business systems, but problematic for systems needing pre-delivery analysis or development by several teams.

Functional Requirements

• Functional requirements describe the services a system provides, responses to inputs, and expected system behavior, and may specify what the system should not do.
• Functional requirements outline the behavior of the software.

Non-Functional Requirements

• Non-functional requirements include constraints on the system's services or functions (timing, development process, standards).
• These requirements often apply to the entire system, and may be more critical than functional ones.

Domain Requirements

• Domain requirements are constraints based on the system's operational domain.

Functional Requirement Characteristics

• Functional requirements describe system functionality or services, based on the software type, expected users, and system context.

• Functional user requirements are general statements about what the system should do.

• Functional system requirements should describe system services precisely and in detail.

• A precise functional requirement should be "A user shall be able to search the appointments lists for all clinics."

• Another precise functional requirement should be "The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day"

• A more precise functional requirement should be "Each staff member using the system shall be uniquely identified by his or her 8-digit employee number."

Completeness and Consistency

• Requirements should ideally be complete with all facilities described and consistent without conflicts or contradictions.
• Complete, consistent requirements documents are unattainable due to system and environmental complexity.

Non-Functional Requirement Properties

• Non-functional requirements define system properties and constraints, like reliability, response time, and storage.
• Process requirements may mandate an IDE, language, or method.
• Non-functional requirements may determine system usability.

Non-Functional Classifications

• Product requirements mandate specific product behaviors like execution speed and reliability.
• Organizational requirements stem from policies, such as process standards and implementation needs.
• External requirements derive from external factors, for instance, interoperability and legislative standards.

Goals and Requirements

• Non-functional requirements are hard to state precisely and verify.
• Goals are general intentions, like ease of use.
• Verifiable non-functional requirements should be objectively testable.
• Goals help developers grasp system user intentions.

Metrics for Nonfunctional Requirements

• Speed can be measured by transactions/second, response time and screen refresh time.
• Size is described as Mbytes or the number of ROM chips.
• Ease of use can be training time or number of help frames.
• Reliability can be mean time to failure, probability of unavailability, failure occurrence or availability.
• Robustness can be time till restart after failure or the percentage of event causing failures.
• Portability can be defined as the percentage of target dependent statements, or number of target systems.

Requirements Engineering Processes

• Requirements engineering processes depend on the application domain, stakeholders, and the developing organization.
• Requirements elicitation, analysis, validation, management are all generic activities common to processes.
• In practice, requirements engineering involves an iterative process with interleaved activities.

Requirements Elicitation and Analysis

• Requirements elicitation and analysis is sometimes called requirements discovery.
• Technical staff collaborate with customers to understand the application domain, system services, and operational constraints.
• Stakeholders, like end-users, managers, and domain experts, are involved.

Requirements Elicitation Stage

• Software engineers collaborate with system stakeholders to understand the application domain, system services, performance needs, hardware constraints, and other system specifics.
• Requirement stages include discovery, classification, prioritization/negotiation, and specification.

Problems of Requirements Elicitation

• Stakeholders might not know their needs.
• may express them in their own terms.
• Conflicting requirements among stakeholders may take place
• Organizational and political factors may affect system needs.
• New stakeholders and business changes may alter the needs during analysis.

Process Activities

• Requirements are discovered by interacting with stakeholders.
• Requirements are classified and organized into coherent clusters.
• Prioritize requirements and resolve conflicts.
• Document requirements and input them into the next phase.

Types of Interviews

• Closed interviews follow a pre-determined questions.
• Open interviews let various issues be explored with stakeholders.

Effective Interviewing

• Have an open mind, avoiding preconceptions, and listen closely to stakeholders.
• Prompt discussions with questions, plans, and prototype collaboration.

Interviews in Practice

• Utilize a mix of closed and open-ended interviews during practice.
• Interviews are helpful for getting a broad understanding of stakeholder tasks and system interaction.
• Interviewers should avoid preconceived notions and prompt the use of the system by suggesting requirements rather than simply asking them.

Problems With Interviews

• Application specialists' technical language can be hard for the requirements engineer to follow.
• Interviews are not ideal in understanding domain requirements.
• Requirements engineers may not understand specific domain terminology.
• Familiarity with domain knowledge may cause those who poses it to not articulate it.

Ethnography

• A social scientist observes and analyzes how people work.
• People don't have to articulate their work.
• Social and organizational factors may be noted.
• Ethnography reveals richer work processes compared to system models.

Scope of Ethnography

• Requirements are based on actual work practices, not prescribed processes.
• It is based on changes resulting from cooperation and awareness.
• Ethnography is great for getting existing processes, but cannot add new features.

Focused Ethnography

• It combines ethnography with prototyping.
• Prototype development leads to questions for ethnographic analysis.
• Ethnography studies existing practices which may no longer be applicable.

Stories and Scenarios

• Scenarios and user stories present real uses of a system.
• They describe the system's role in a task.
• Stakeholders relate and comment on their stories based on these situations.

Scenarios

• A structured form of user story.
• Should include descriptions of starting situations, normal events, errors, other activities and final stats.

Requirements Specification

• Requirements specification involves documenting user and system requirements in a requirements document.
• User requirements needs to be understandable without technical knowledge.
• System requirements are more thorough and might have more technical information.
• The requirements may create the system.
• It is important to be complete as possible.

Requirements and Design

• In theory, requirements state what a system should do, and design explains how these tasks should be achieved.
• In practice, requirements and design are inseparable.
• System architecture may be structured the requirements.
• The system may generate design requirements.
• Satisfying non-functional requirements using specific domain needs could result to having the consequence of regulatory requirements.

Natural Language Specification

• Uses natural language with diagrams/tables.
• Requirements can be understood by users and customers, as it is intuitive and universal.

Guidelines for Writing Requirements

• Requirements should use a standard format.
• Use consistent language like "shall" for mandatory items and "should" for desirable ones.
• Highlighting makes it clear which parts stand out
• Avoid computer jargon.
• Explain why each requirement is necessary.

Problems with Natural Language

• Achieving precision compromises readability.
• It is difficult to differentiate between Functional and non-functional requirements.
• Requirements may be mixed together.

Structured Specifications

• Reduces freedom in writing requirements and puts them in a standerd way.
• Works well for systems that come pre installed.
• Writing for business systems can be too ridgid.

Form Specification Elements

• Function/entity definition.
• Input descriptions and sources.
• Output descriptions and destinations.
• Needed data and other entities.
• Action description.
• Pre and post conditions when appropriate.
• The function should also include any side effects.

Tabular vs Natural Language

• It should supplement natural language.
• Use it to defining alternative actions.
• It calculates requirements in scenarios.

Use Cases

• Included in the UML.
• Identify actors and interactions.
• Should describe any possible system interactions.
• It is high-level and supplemented with description
• UML diagrams show sequences to use-cases.

Software Requirements Document

• What is required for software developers is in the requirements document.
• Definition of the user and system requirements are contained
• Its not a design, it presents the intention and not the implementation.

Users Document

• It should specify requirements that match the customers needs.
• Use the document to plan to plan bids for the system and design an implementation process.
• Use documents understand all system implementations.
• Documents should specify the validation tests.
• Use the implement the system and and show relationships between sections

Requirements Document Variability

• Info variety depends on document approach.
• Incremental systems have less details in documents
• There are IEEE standards for this which are specific to projects of engineers.

Validating Requirements

• Requirements must match customer needs.
• High error cost is important.
• Fixing errors post delivery is 100X costing.

Requirements Checking

• Ensure validity by providing functions for needs of customers.
• Eliminate potential conflicts.
• Include the requests made by all customers?
• Implementation given budget can be implemented and is verifiable.

Validation Techniques

• System analysis of the requirements.
• System checks using an executable model.
• Developing test check testability.

Requirements Reviews

• Requirements need to be formulated and have scheduled reviews
• Reviews should involve client and contract staff.
• Formal docs are formal; developers/users communicate are informal which resolve issues.

Review Checks

• Verify are they actually there
• Understand if its properly understood.
• Make sure origin is clear.
• Adaptability shouldnt require significant work.

Changing Requirements

• Post installation there will be business system and environment change, which requires new things.
• The people should not be the same for both system and user needs.
• Requirements management ensures you keep track of all documentation and maintain links to make sure changes to requirements get tracked.

Requirements Management planning

• Establish all details for management.
• Identify, A and T are all part of key management.
• Identify uniquely to cross referencing is important.
• Change assessment includes impact with set activities.
• Record policies between A and S.
• Support with tool and database for all range specialists.

Requirement Change Management

• It will be determined if the change can or should be accepted.
• With the analysis that is problem based you change its specified and checked for valid which require requestion of those changes.
• Asses them using the information related to the system
• Implementation of the needed system document or system designs/implementations needed have them changed/modified.