Requirement Engineering

Part (1)
- The process of establishing services and its constrains, that a customer needs in a system
- System Requirements are the description of the system services and its constrains
Requirement:
- It ranges from a high-level abstract statement of a service or a system constrain to a detailed functional specification
Types of Requirements
1) User Requirements
- Statements written in natural language & Services that the system provides, written for customers
2) System Requirements
- Structured Document setting out detailed specifications of the system’s functions, services and constrains
3) Functional Requirements
- Describes the functionality or system services, depends on the type of software, users and the system
4) non-Functional Requirements
- Constrains applied to the services or functions offered by the system, Often applied to the system as whole
5) Domain Requirements
- How the system should react to particular inputs
System Stakeholders:
- Any person or organization who is affected by the system & interested in it
Types of Stakeholders:
- End users
- System Managers
- System Owners
- External Stakeholders
Requirement Imprecision
Part (1)
- Problems arise due to the imprecision of stating the requirements
- Ambiguous Requirements can be interpreted in different ways by users & developers causing confusion
Requirement Completeness
- They should include descriptions of all system facilities required
Requirement Consistency
- There should be no conflicts in the descriptions of the system facilities
Product Requirements
- Specify that the delivered product must behave in a particular way
Organizational Requirements
- A consequence of organizational policies & procedures
External Requirements
- Arise from factors which are external to the system & its development state
Goals and Requirements
- Non-functional requirements may be difficult to state precisely & imprecise requirements are hard to be verified
Goal
- A general intention of the user
Verifiable non-functional Requirement
- A statement using some measure that can be objectively tested
Metrics For specifying non-functional
Part (1)
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
Requirements engineering processes
- Processes used for RE vary widely depending on the application domain, the people involved in developing the requirements
Types of Processes
1) Requirement elicitation
2) Requirements analysis
3) Requirements validation
4) Requirements management
Requirements Elicitation (Discovery)
- Involves technical staff working with customers to find the services that’s the system should provide & its constrains
- May Involves End users, managers and engineers
It includes:
1) Requirements Discovery
2) Requirements Classification & Organization
3) Requirements Prioritization & Negotiation
4) Requirements Specification
Problems with Requirements Elicitation
- Stakeholders don’t know what they really want
- Stakeholders express requirements in their own terms
- Different Stakeholders might have conflicting Requirements
- New Stakeholders May emerge and change the entire enviroment
Process activities
- Requirements Discovery:
Interacting with stakeholders to discover their requirements.
- Requirements classification & organization
Groups related requirements and organises them into coherent clusters.
- Prioritisation and negotiation
Prioritising requirements and resolving requirements conflicts.
- Requirements specification
Requirements are documented and input into the next round of the spiral.
Types of Interviews:
- Closed Interview based on pre-determined list of questions
- Open Interview various issues are explored with stakeholders.
Effective Interviewing: Be open-minded, avoid pre-conceived ideas about the requirements
and are willing to listen to stakeholders.
Interviews in practice: Normally a mix of closed and open-ended interview
Problems with interviews:
- Interviews are not good for understanding domain requirements
- Application specialists might use languages to describe the requirements that is not easy for the requirements engineer to
understand
Ethnography:
- A social scientist spends a considerable time observing and analysing how people actually work.
- Social and organisational factors of importance may be observed.
Scope of ethnography:
- Requirements that are derived from the way that people actually work
- Requirements that are derived from cooperation and awareness of other people’s activities.
- Ethnography is effective for understanding existing processes but cannot identify new features
Focuses ethnography:
- Developed in a project studying the air traffic control process
- Combines ethnography with prototyping
Stories and Scenarios:
- Scenarios and user stories are real-life examples/description of
how a system can be used.
Requirements Specification:
- The process of writing down the user and system requirements in a requirements document.
- User requirements must be understood by End-users, System requirements are more detailed
Requirements and Design:
- Requirements should state what the system should do and the design should describe how it does this, these
two phases are inseparable
Natural Language Specification:
- Requirements are written as natural language supplemented by diagrams & tables so it can be understood by users/customers
Guidelines for Writing Requirements:
- Invent a standard format
- Use language in a consistent way
- Use highlighting for key parts of the requirements
- Include a brief summary on way the requirement is important
Problems with Natural Language:
- Lack of Clarity
- Requirements Confusion
- Requirements Mixing
Structured Specifications:
- An approach to write requirements where the freedom of the requirement is writer limited, and written in the standard form
Form Based Structure:
- Includes the case name, Actors, Description, Pre and Post conditions, Basic flow and Alternative flow (if exist)
Tabular Specification:
- Used to supplement natural language, useful if you have to define many possible alternative flows
Use Cases:
- Scenarios that are included in the UML
- Identifying the actor in a certain interaction, which describes the interaction itself
- Describes all possible interactions with the system
Software Requirements Document:
- Official statement of what is required of the system developers
Requirements Validation:
- Concerned with demonstrating that the requirements define the system that the customer really wants
- Requirements error costs are high so validation is very important
Requirements Checking:
Validity -> Does the System provide the functions which best support the customer’s needs?
Consistency -> Are there any conflicts?
Completeness -> All the functions required by customers included?
Realism -> Can the requirements within budget?
Verifiability -> Can the requirements be checked?
Requirements Validation Techniques:
- Requirements reviews
- Prototyping
- Test-case Generation -> Developing tests for requirements to check testability
Review checks
Verifiability -> Is the requirement testable?
Comprehensibility -> Is the requirement properly understood?
Traceability -> Is the origin of the requirement clearly stated?
Adaptability -> Can the requirement be changed without an impact?
Changing Requirements:
- Business & Technical environment always change after installations, as new hardware or software could be introduced
- People who pay for the system & users of the system are rarely the same
Requirements Evolution:

Requirements Management:
- Is the process of mange the changing requirements during the requirements engineering process
Requirements Management Planning:
- Establishes the level of requirements management details that are required
Requirement Management Decisions:
- Requirements Identification
- A change management process
- Traceability policies
- Tool support tools
Requirements Change Management:
- Problem analysis & change specification
- Change analysis & costing
- Change Implementation