Requirements Engineering Flashcards
What are introduced during requirements activities?
40% - 50% of defects
Why are requirements hard to define?
Informal requirements gathering
Not being able to articulate what is needed
Implied requirements, details implied from domain specific knowledge
Miscommunicated assumptions
Types of Requirements?
Functional Requirements
Non-Functional Requirements
Functional Requirements?
What the software is required to do
Exist at different level of abstractions, from high-level to detailed functional requirements
The features of the software systems
Non-Functional Requirements
Technical Requirements
How well is the software supposed to do what it is required to do
Constraints of different types on the software system
Quality requirements. The required-ilities the system must exhibit
External interfaces of other systems that the system under development must interact with
List Functional Requirements?
Business Requirements
User Requirements
Functional Requirements
Business Requirements?
Describe why the organization is implementing the system
Identify high-level business objectives of the customer
Typically documented in plain English in a vision and scope document
User Requirements?
Describe what the system does at a high-level
User goals and the high-level tasks performed by users
User requirements are sometimes grouped into features
Functional Requirements?(List)
Specify how the user-goals are accomplished, the detailed steps that users must carry out to accomplish their goals
Describe what developers must implement
Business requirements are defined by?
Business managers
and/or
Marketing departments
User requirements are derived from business requirements by?
The business/system analyst
or
Product manager
Functional requirements are defined by?
The analyst
Non-Functional Requirements Definition?
Define how well the software does its job.
Technical Requirements List
Product Requirements
Organizational Requirements
External Requirements
Constraints on the functional requirements of the system?
Timing, speed, memory, security, regulatory
Quality requirements?
Usability, maintainability, reliability, portability
External interfaces required for the system to interact with?
Existing infrastructure
External systems
Domain driven design aims at defining?
A ubiquitous language that is understood by both domain and software experts
Domain modelling helps define?
The ubiquitous language through a model and a glossary of terms
Requirements Development Activities?
Elicitation (Communicate)
Analysis (Think)
Specification (Write)
Validation (Verify)
Inception Iteration (Sprints)
- Define business requirements
- Identify user classes
- Identify user representatives
- Identify requirements decision makers
- Plan elicitation
- Identify user requirements
- Prioritize user requirements
Elaboration Iterations (Sprints)
- Flesh out user requirements
- Derive functional requirements
- Model the requirements
- Specify nonfunctional requirements
- Review requirements
- Develop prototypes
- Develop or evolve architecture
- Allocate requirements to components
- Develop tests from requirements
- Validate user requirements, functional requirements, nonfunctional requirements, analysis models, and prototypes
Requirements Elicitation?
The discovery of requirements. Identify product's categories of users and stakeholders Determine the business objectives Understand the user goals Understand the environment
Stakeholder viewpoints?
Interactor viewpoint of primary actors
Indirect viewpoint of supporting actors
Domain viewpoint of the environment
Establish a ubiquitous language that?
Both domain experts and technical experts understand and agree on
Elicitation Techniques?
Elicitation Interviews
Elicitation Workshops
Observation / Ethnography
Elicitation Interviews?
Individual or in small groups
- Effective without taking too much stakeholder time
- Closed interviews have a set of predefined questions
- Open interviews are exploratory and have general goals
Elicitation Workshops?
In larger groups but not too large
- Facilitated sessions with multiple stakeholders and diverse types of stakeholders not just customers like developers and testers
- Resource intensive with numerous participants
- Must be well-planned
Observation / Ethnography?
To discover the state of practice
- Time consuming, used for important high-risk tasks involving multiple types of users
- Silent or interactive, might use video recordings if allowed / appropriate.
Requirements Analysis?
Analyze Requirements
Decompose higher-level requirements to lower level requirements
Derive precise functional requirements from user-requirements
Model the application environment and the requirements of the project at different levels of abstraction
Create prototypes to validate requirements
Prioritize requirements and analyze feasibility
Detailed requirements are recorded in a?
Structured format that is consistent, accessible, reviewable, easy to understand.
Business requirements recorded in a?
Vision and scope document
User requirements are recorded as?
Use-cases or stories
Functional requirements are recorded as?
Use-case scenarios or story conversations and acceptance criteria
The detailed functional and non-functional requirements are recorded in a?
Software Requirements Specification
Requirements Specification Good Practices?
Develop and use a standardized template for recording requirements
Uniquely identify each requirement to allow effective requirements management
Identify and maintain the origin of all requirements to allow the traceability need to manage change
Record business rules and other domain requirements separately as they represent an enterprise-level asset
Record the non-functional requirements to ensure the product satisfies quality expectations and other constraints
Requirements validation?
Confirms that we have correct requirements.
Review the recorded requirements through requirement inspection
Develop system tests from recorded requirements
Define the acceptance criteria used by users to determine that the resulting system is suitable and has met the requirements
System tests from recorded requirements?
Ensures requirements are testable which eliminates ambiguities and vagueness and can also highlight conflicts
Tests can be easily derived from requirement when these are recorded.
Building a requirements model?
Will define a model of the system from a requirements perspective.
System Context Diagram?
Defines the scope of the system
List requirements model components?
System Context Diagram
Business Requirements
Actors
Functional Areas
Use-cases are?
Text documents, not diagrams, that describe related success and failure scenarios of iteration between actors and SuD.
Use-Case Diagrams show?
Which actors interact with which use-cases and how use-cases related to each other
Use-Case Model?
Is the collection of a written use-cases, actors, and use-case diagrams.
Types of Actors?
Primary Actor
Supporting Actor
Offstage Actor
Primary Actor?
A type of user of the system under discussion (SuD) that uses the system in order to achieve specific goal.
Example of Primary Actor?
Cashier using a POS system
Supporting Actor?
An actor that provides a service to the system under discussion
Example of Supporting Actor?
Twitter as used in an e-commerce application or payment authorization system like PayPal
Offstage Actor?
A stakeholder that does not interact directly with a system but has interest in.
To ensure all requirements have been identified
Example of Offstage Actor?
Government Agency
Relationships in Use-Case Diagrams?
Association
Dependency
Generalization
Association?
Used between actor and use-case
Shows the communication of the actor with the system under discussion
Dependency?
“Include” relationships are dependencies with the <> stereotype showing one-use using another
“Extend” relationship are dependencies with the <> stereotype showing alternative or exceptional scenarios
Generalization?
Is-A Relationship with the same reusability semantics as in class diagrams. Used between two actors or two use-cases
Fully Dressed?
Use-cases are structures and show more detail allowing for more complete requirements and less risk
