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
What is the rationale for requirements management?
Requirements connect business objectives with business outcomes and so are central to business success, meaning control is necessary.
Projects can be large, long term, interrelated and subject to extensive change. Without control, there will be chaos.
What are the elements of requirements management?
1) Identification - each requirement and configuration has a unique identifier. Configurations are set of requirements, models or items that make up deliverables.
2) Cross reference - identifies requirements related to the one that is changing and related documents too. Basis for impact analysis.
3) Origin - person or a document. Provides additional information. Justifies (or not) inclusion.
4) Ownership - mechanism for traceability. Allows clarification, prioritization, deconflict, escalation.
5) Version control - ensures requirements/configuration items aren’t change without approval and new versioning
6) Change control - documenting proposed change (who and why), analysing impact, consulting stakeholders, making decision to accept or reject.
7) Storage - software can help here.
What is requirements traceability?
Vertical traceability.
Demonstrates the relationship between the requirements and the business objectives.
Solution requirements -> Business requirements -> Business objectives/strategy.
Ensures alignment
ii. Horizontal traceability
Forward from requirement to feature, and backward from feature to requirement.
Enables you to identify the source of the change and/or whether a requirement was met in the solution.
Means we know who to talk to clarify, prioritize or deconflict.
What is the difference between requirements validation and verification?
Validation
- “Are we building the right thing?”
- Checks that the requirements accurately capture what the user wants and that the system, when developed, will satisfy those needs.
Verification
- “Are we building it right?”
- Ensures that the system’s requirements are well-formed, feasible, and technically correct. It checks the internal consistency of the requirements.
Both are crucial for successful requirements engineering, with validation concentrating on user satisfaction and verification on technical correctness.
What is requirements management?
Gathering, recording, analyzing, validating, verifying, managing changes to and tracking requirements throughout the lifecycle.
What are common sources of requirements change?
Change of key stakeholders
Change in project scope
Change in legislation
Altered business priorities
Competitor action
New technology
Change of mind
Better understanding of need.
Why is change control important?
The purpose of which is to create a robust audit trail of any changes to ensure any changes made are justified.
Without it, chaos ensues.
What is the change control process?
Documenting proposed change (who and why)
Analysing impact (time, cost, risk, scope, benefits, quality)
Consulting (representative) stakeholders
Designated approval authority makes decision to accept or reject.
If approved, the configuration item is release so a new version can be created.
Some companies and some changes require formal Change Control Boards.
Some can be reviewed by the business analyst.
Sponsor may need to make the final decision.
What is configuration management?
- Identification of all the components to be managed eg. requirements, sets of requirements, software code, documentation, hardware with a unique ID for each.
- Change control
- Status accounting - to record current state of each configuration item. eg. which versions are in use, which are in development
- Auditing - reviewing the actual state of the system against the expected state to ensure everything has been properly applied.
- Baseline management - formally approved versions of configuration items which serve as reference points.
All help maintain traceability and integrity.
What are the different levels of configuration item?
- Individual components - smallest, discrete parts of a system eg. files, hardware parts
- Subsystems - related components that perform a specific function eg. UI package
- Systems or products
- Project or service level
What functionality should be considered when comparing tools for requirements management?
- Storage of documentation and models.
- Linkage and cross-referencing.
- Change and version control.
- Access restrictions.
How do legal issues guide the choices of business analysts?
Business analysts must perform their role with an awareness of legal obligations.
We must identify circumstances and raise them with stakeholders when requirements contravene laws and regulations.
eg. disability access or data protection.
What is the purpose of the various elements of the requirements catalogue?
i. Identifier.
ii. Name.
iii. Description.
iv. Business area.
v. Type of requirement.
vi. Author.
vii. Source.
viii. Owner.
ix. Priority.
x. Rationale/justification.
xi. Cross-referenced
requirements.
xii. Cross-referenced
documents.
xiii. Acceptance criteria.
xiv. Status/resolution.
xv. Version number and date.
i. Identifier - reference to help track, manage and refer.
ii. Name - easy reference.
iii. Description - what it is and what it is expected to achieve. Enough information to ensure understanding.
iv. Business area - helps identify relevant stakeholders for validation.
v. Type of requirement - category to help understand nature.
vi. Author - context and intent.
vii. Source - person or document. Helps traceability.
viii. Owner - ensures it is reviewed, updated, fulfilled.
ix. Priority - identifies what needs to be done when.
x. Rationale/justification - context or necessity.
xi. Cross-referenced requirements - identifies dependencies or conflicts.
xii. Cross-referenced documents - supporting document.
xiii. Acceptance criteria - conditions under which it’s considered complete.
xiv. Status/resolution - helps track progress. eg. proposed, approved, in progress, complete
xv. Version number and date - aids change control.
What is a user story and why is it used?
Key part of agile methodologies.
They provide a simple, concise description of a feature or function from the point of view of the end user.
Format: As a [type of user], I want [some goal] so that [some reason/value].
Also has title, acceptance criteria and additional notes.
Three Cs:
Card: A written summary of the user story (who, what, why).
Conversation: A dialogue to clarify details and functionality.
Confirmation: Acceptance criteria to confirm when the story is complete
Together, the 3Cs highlight that user stories are not just static requirements but evolve through collaboration and clear agreements.
Name four methods of requirements documentation
Use case diagram
User stories
Data model
Requirements catalogue
What is a use case diagram and why is it used?
The primary purpose is to visually represent the functional requirements of a system and how external actors (users or systems) interact with it. They also help to define scope, showing the boundaries of the system.
Often used in requirements engineering and system analysis.
Parts:
Actors
Use cases
System boundary
Associations
Part of the Unified Modeling Language (UML)
Clear an simple, helping to facilitate communication.
What types of data models are there and why are they useful?
Visual representation of the relationships between entities in a database, showing how data is structured and connected. aka Data Model
Clarifies what data will be recorded so stakeholders can agree it fulfills their purposes.
Clarifies business rules around data.
Blueprint for database design.
Entity relationship diagram
Class diagram (UML)
Why is it useful to model requirements?
Help business to understand scope and scale before work commences.
Each model represents a particular viewpoint, but they are all concerned with a particular system, so cross checking between then can help identify inconsistencies or omissions.
Usually more easily and more quickly understood that writing.
What are class models?
Part of the Unified Modeling Language (UML)
Class model is a graphic representation of all the classes in a business system and their associations with each other.
Class: Defines a group of objects with shared attributes and behaviors. eg. car.
Object: Instance of a class, representing a specific entity with defined attributes eg. grey Citroen C4 with number plate xxxxxx
Attribute: property or characteristic of a class eg. colour
What is a CRUD matrix?
Records the event, use case or process that causes and entity or class to be created, read, updated or deleted.
Helps with cross referencing models.
