Requirements
The aim of the requirements is to answer the question
What must the product be able to do
- We must determine what the client needs
- Misconception - We must determine what the client needs
- Ex. The client wants a faster software, but the real problem is the database is poorly designed
High-Level Requirements
- Give a general description of what it is the system should do
Low Level Requirements
- How the system should accomplish these goals
Functional Requirements
- Specifies an action that the software product must be able to perform
- often expressed by inputs and outputs
- Shouldn't be too vague
- Calendar - bad example
Nonfunctional Requirements
- How the system is supposed to be, the constraints
- Time, ability, scalability, security, reliability
- Shouldn't be too vague
- Fast, pretty, dark mode - bad example
- Some may have to wait until later workflow
Requirements engineering
1) Requirements elicitation
- Research and discovering the requirements
- Accomplished through discussion with stakeholders and dev team
1) Sufficiently understand the application domain and terminology
2) Discover the real requirements of the stakeholders
3) Group-related requirements and organize them
4) Prioritize the requirements and resolve requirements conflicts
5) Document requirements
2) Requirements specification
3) Requirements validation
Stakeholders: any person who is affected by the system in some way and has a legitimate interest
- Client, players, retailers, community
Application Domain
- Represents the context/environment in which the application is intended to operate
- Banking, Education, Game, Etc
- We can't fully understand the application domain
Requirements Discovery
- The process of gathering information about required and existing systems
- Interaction with stakeholders is from managers
- Formal or informal interviews with stakeholders are part of most RE processes
1) Structured interviews, preplanned questions
2) Unstructured interviews, conversation
3) Semi-structured interviews, preplanned and conversation
Types of Interview Questions
Open Ended - Require a specific answer
Close Ended - are posed to encourage the person being interviewed to speak out
Observational Method - Job Shadowing
- Observing users or stakeholders
- Two Types...
1) Passive Observation - The analyst watches someone working but does not interact with them in any way
2) Active Observation - where an analyst asks questions through the process to make sure he understands
Prototyping/Mockups
- provide visual representations of a system that are used to elicit, analyze, and validate requirements
- They only exhibit the key functionality
- Humans are better at recognizing if a solution is correct than solving a problem from a blank page. Help explore uncertainty in the requirements