Requirements Engineering Flashcards
For International Diploma in Business Analysis (Viva)
What is the requirements engineering framework?
It demonstrates the relationship between the typical stages of the requirements engineering process.
The non-linear nature allows flexibility in the order of completion
Repetition as required.
Stakeholder engagement and consultation is necessary throughout this framework
What is a requirement?
A feature that the business staff need the new system (business or IT) to provide.
Vital step between problem and solution. Identify the needs in the presence of problems.
They should be solutionless.
What is the hierarchy of requirements?
What is the rationale for requirements engineering
- Reduces risks (eg. scope creep)
- Improves quality (eg. basis for validation and verification)
- Improves efficiency (as resources can be estimated up front and planned accordingly)
- Ensures alignment between solution and stakeholder expectations
What are general business requirements?
Specifications that apply across all projects.
Legal eg. legislative or regulatory
Business policies - eg. standards
Business constraints - eg budget
Branding and language eg. image, style
Cultural - eg. management style
What are technical business requirements?
Specifications that relate to IT technical infrastructure that apply across all projects.
Hardware
Software eg. operating systems
Interoperability eg. standard for communicating between systems
Internet eg. use of
What are functional solution requirements?
What the (IT) system has to do.
Often modelled as use cases
Create
Read
Update
Delete
What are non-functional solution requirements
Specifications on how the functionality is delivered.
Performance eg. speed of processing
Security
Access
Backup and recovery
Archiving and retention
Robustness eg. reliability
Availability
Usability
Capacity eg. volumes
Please Save All Backups and Run Apps Under Capacity
How are requirements related to objectives and solutions?
Objectives represent the high-level goals that a system/project aims to achieve and typically align with organisational strategy.
Requirements define what the system must do to meet objectives, translating them into actionable details or a blueprint for the solution.
Solutions are the systems designed to meet the requirements.
What are the different types of knowledge?
Explicit knowledge: what you know you know.
Formal, often documented, and easily shared.
Tacit knowledge: what you don’t know you know.
Personal, experiential, and often unarticulated.
eg. Taken-for-granted information, tacit assumptions, unconscious skills, intuitive understandings, cultural norms.
What are the best tools for requirements elicitation?
Both linear and agile:
- Interview, workshops, prototyping, scenario analysis, modelling
Linear only:
- Document analysis, observation, shadowing, special purpose records
What are the best tools to uncover tacit knowledge?
Scenario analysis, protocol analysis, prototyping
What is the difference between elicitation and analysis?
Requirements don’t appear fully formed and complete. They need to be cleaned, assessed and prioiritised.
What quality criteria should requirements be tested against?
i. Testable.
ii. Unambiguous.
iii. Relevant.
iv. Clear.
v. Complete.
vi. Consistent.
vii. Traceable.
What are the tasks involved in requirements analysis?
- Categorising - business or solution
- Quality assurance
- Relevance check - aligned to business/project objectives
- Feasibility check - technical, business, financial
- Atomic, distinct, conflict free
- Solution free
- Packaging for deliver eg. user, verb, noun
Name a method for assessing priority?
MOSCoW
Must have - mandatory
Should have - mandatory but may be deferred
Could have - desirable
Want to have - but won’t this time
What is the difference between contradictory and conflicting requirements?
Contradictory requirements cannot be achieved together due to direct opposition.
Conflicting requirements can both be achieved but require balancing or trade-offs.
Why are user role analysis and personas helpful in requirements analysis?
User role analysis helps in identifying the various user groups that will interact with the system.
Each group may have different needs and priorities.
Understanding these can help tailor the system to meet those needs effectively.
Essential when there would be too many stakeholders to talk to individually.
For each user role, potential sub-groups are identified that share overall membership in the user group but differ in how and why they might interact with a solution.
Personas are low-level archetypes, fleshed out with enough details to make them seem ‘real’
They help stakeholders to understand why and how individuals might interact with the solution.
What is the rationale for requirements validation?
Reviewing requirements with stakeholders to ensure that they are accurate, feasible, and aligned with the project’s goals, while also facilitating better communication and understanding among stakeholders
What is the requirements validation?
A stakeholder group review for the purposes of finding deficiencies in requirements.
Objective is to increase quality of the requirements developed and increase user confidence in that development.
The idea is to:
- catch errors and reveal omissions
- establish user buy in
- check adherence to standards
Who is usually involved in requirements validation and in what capacity?
Chairperson - to control the review
Business analyst - to provide information about the requirements
Business sponsor - ensure they’re aligned with business objectives and are in scope
Business owners - ensure they’re clear and correct
SMEs - ensure they reflect correct business practice
Solution architect - ensures they’re achievable within the enterprise architecture
Developers - ensure technical feasibility
Testers - ensures they’re testable
Project team - ensure they’re compliant
What is the requirements validation process for a linear project?
- Evaluated at the detailed level, ready for development.
- Final opportunity to confirm and accept requirements.
- The level of formality will depend on the characteristics of the project eg. compliance issues, strategic importance, budget etc.
- Reviews can range from quick informal reviews with the sponsor, to formally documented structured review with all the main stakeholders.
- If the project is large, a section-by-section review may be done instead
What are the three possible outcomes of a formal review?
Significant rework and another review required
Some amendments required which can be signed off by the business sponsor
Confirmed and signed off. Requirements are baselined.
After sign off, all changes are baselined and subject to formal change and version control.
What is the requirements validation process for an agile project?
Validation should occur when it is useful.
Requirements will be validated more than once at different stages of the project.
When initiating the project, the outline solution is determined an a backlog is established.
A more formal review may be done to ensure that general requirements and key solution requirements are understood.
When maintaining the backlog, work items are refined until they are deemed ready to progress. This is an ongoing process. Only items with the highest priority need to be ready.
Refinement may include:
- Checking alignment with solution design
- Producing prototypes
- Developing and discussing scenarios in use cases/user stories
- Building models eg swimlane diagrams
- Defining acceptance criteria
- Separating large items into smaller ones
