Requirements Engineering (WK3&4) Flashcards
What is a requirement and why do we care?
A requirement tells us what the system needs to do (not at an implementation level)
Requirements engineering is the process of establish what a customer required from a system and the constraints under which it is operated/developed.
User and system requirements
User requirements: written for customers, statements in natural language/diagrams describing services provided and operational constraints
System requirements: What is needed to run. Defines what should be implemented
System stakeholders
Any person/organisation who is affected by the system or who has a vested interest in it. Some stakeholder types: end users, system managers, system owners, etc. Software engineers aren’t stakeholder in their own system for the purposes of this course.
What are the four requirements engineering processes?
- requirements elicitation
- requirements analysis
- requirements validation
- requirements management
Completeness and consistency
Requirements should be complete and consistent
Completeness: they should include descriptions of all facilities required
Consistency: there should be no conflicts or contradictions in the descriptions
Domain Requirements
Constraints on the system from the domain of operation (areas where the reqs reside)
Ex: database, User interface, distributed system
These can be formed from functional ornon-functional requirements, and canconstrain the already defined system requirements.These are generally more technically-based,and ensure that the system will actually work onceimplemented.
Functional Requirements
Describe functionality or system services.
Examples:
- When a grade is released, a notification shall be given to the student on their course dashboard
- All students can log in to the course system using their unique student ID number
Non-functional requirements
Define system properties and constraints (eg. reliability, response time, storage req, etc). May be more critical than functional requirements, and a single non-functional requirement may generate multiple functional requirements.
Examples:
-The online course system shall be available to all users 24/7 and non-planned downtime shall not exceed ten seconds in any one day
-Video-based course materials shall be available tostudents in at least 480p quality
Classifications of non-functional requirements
Product requirements: specify how the product must behave
Organisational requirements: req stemming from organisational policies/procedures (such as standard processes)
External requirements: arise from external factors such as legislative requirements, regulatory/ethical, accounting, etc.
Metrics for specifying non-functional requirements
Examples:
- Speed (transactions/second, response time, 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)
- robustness (time to restart after failure, probability of data corruption on failure)
Methods for eliciting requirements
Individual interviews: private and in-depth, but, time-consuming and not good for domain requirements.
Focus groups: peer interactions, uncover a lot in a short time, but, may be dominant speakers, peer pressure, and its dependent on the moderator.
Scenarios: using examples. Can criticise how they might interact with the software system.
Ethnographic studies: observational study of behaviours. Effective for understanding existing processes.
What are some different ways of specifying requirements?
- natural language
- structured natural language (using form or template)
- design description languages
- graphical notations (UML use case and sequence diagrams)
- mathematical specifications
Natural Language for requirements specification
Guidelines for writing requirements: invent a standard format, use text highlighting, avoid the use of jargon, include an explanation of why its necessary.
Problems with natural language: lack of clarity, requirements confusion (functional and non-functional), requirements amalgamation (several may be represented together)
Structured requirements specifications
Example structure:
- Definition of function or entity
- description of inputs and outputs
- information needed for computation
- description of action to be taken
- pre and post conditions (if applicable)
- side effects (if any)
Use cases
High-level graphical model to visualise the system design with actors. See mentcare example.
UML sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.
