4. Requirements Definition Flashcards
4.1 Requirements Engineering 4.2 Requirements Elicitation 4.3 Requirements Analysis 4.4 Requirements Validation
4.1 What is a requirement?
+ A representation of a need (BR).
+ A condition that must be satisfied in order to solve a problem or achieve an objective (NFR).
+ A function that a system does (FR).
4.1 What are requirements for?
+ To give stakeholders the ability to clearly and unambiguously say what they need/want
4.1 Why is it important to get requirements right?
+ Many projects fail because of poor requirements
+ Errors found at the requirements engineering stage are significantly cheaper to address than when found at later stages of the development lifecycle
4.1 How are requirements used by the following stakeholders?
Users/Customers Developers Testers Project Sponsor BA Business Managers
Users/Customers:
+ Provides the basis for user acceptance testing before release.
Developers:
+ Forms the basis of coding the solution (development)
Testers:
+ Provides the basis for creating test cases
Project Sponsor:
+ Used as an audit trail to ensure benefits identified in business case are delivered in the final solution.
BA:
+ A key deliverable.
+ Used for traceability and ensuring all relevant stakeholders have been engaged in the process.
Business Manager:
+ Used to monitor progress through subsequent stages of the design lifecycle
+ Forms the basis for formal sign off to enable progression to the next stage of the development lifecycle
4.1 What are some challenges when obtaining and defining requirements from stakeholders?
+ Unrealistic expectations
+ Lack of skills/experience by the business analyst
+ Involvement of the wrong stakeholders
+ Not having access to all the right stakeholders
+ Internal politics
+ Tacit Knowledge
+ Conflicting stakeholder needs/priorities
+ Stakeholders may want to give solutions as needs
4.1 What is the rationale for requirements engineering?
+ Lowers the risk of a project failing, as a significant number of projects fail because requirements have not been:
+ Analysed with enough precision to ensure they have sufficient detail
+ Validated with users over time to ensure they are correct and complete
+ Documented and stored properly to ensure traceability
4.1 What are the elements of the requirements engineering approach?
+ Requirements Elicitation
+ Requirements Analysis
+ Requirements Validation
+ Requirements Documentation (functional and data models, elicited requirements list, structured requirements catalogue, baselined requirements catalogue, requirements document)
+ Requirements Management (storage, security, change and version control, traceability)
4.1 What is the hierarchy of requirements?
Business Requirements General & Technical . . Solution Requirements Functional & Non-Functional
4.1 Define different types of Business Requirements and different ways of grouping them in the requirements catalogue.
General:
These are high level business requirements from which lower level requirements are generated
Group by: Projects constraints such as budget and timing Legal constraints Company policy constraints Look and feel standards
Technical:
These are requirements that specify the technical architecture of a solution
Group by:
Hardware constraints
Software constraints
4.1 Define different types of Solution Requirements and different ways of grouping them in the requirements catalogue.
Functional
These requirements specify the functions the solution must provide
Group by:
Use Case
Business area
Access Type
Non-Functional
Requirements that specify how the solution should operate
E.g. Performance Usability Accessibility Scalability etc.
4.1 Give an example for each type of requirement.
General
The front end should use official bank colours and logo
The application must comply with data protection legislation
Technical:
The solution must run on Windows OS
Functional:
The solution should be able to query an existing record
The solution should print a regular report
Non-Functional
The solution should return customer a/c balance in 2 seconds
The solution should be able to have 5M concurrent users
4.1 Why is planning for requirements engineering process important?
+ Ensures that the requirements activities undertaken are appropriate
+ Ensures work effort is coordinated
+ Ensures that the team has a common understanding of what activities they are undertaking
+ Ensures that the tools, resources and stakeholders are available as needed
+ Deciding on the change and version control process ensures requirement changes are captured correctly and consistently
4.1 What are some activities involved in requirements planning?
+ Create and agree the PID with the project sponsor
+ Agree estimation approach with project manager
+ Decide SDLC methodology (Waterfall vs Agile)
Elicitation
+ Get introduced to main stakeholders
+ Stakeholder management: identify stakeholder responsibilities (create RACI chart) and Prioritise Stakeholders (create Power/Interest Grid and User Analysis Matrix)
+ Select requirements gathering approach
Requirements Management
+ Plan what the change management and version control process will be
+ Decide how requirements will be stored and use of CASE tool
4.1 Every RE project should start off with a PID.
What’s an example of a business and project objective in the PID?
Business Objective:
To improve customer perception of the brand by reducing processing time
Project Objective:
To investigate current processes that handle customer requests and to identify and implement improvements that shorten processing time from 5 to 2 days by Nov 1
4.1 What is a technique that you can use to identify the most relevant end users to engage with?
User Analysis Matrix
Users are placed on a matrix (with 4 quadrants) based on two criteria:
- How frequently they are expected to use the system
- Whether it is optional or mandatory to use the system
The BA then engages with at least 1 representative from each quadrant
4.1 Who are the stakeholders in requirements engineering?
Internal Business Stakeholders: project sponsor, end users, business managers, SME
Project Stakeholders: project manager, BA, developer, tester, solution architect
External: customers, suppliers, regulators, competitors, shareholders, partners
4.1 What are the responsibilities of the following stakeholders in requirements engineering?
Project Sponsor End User SME PM BA Tester Solution Architect
Project Sponsor:
+ Commission the project
+ Responsible for delivering the business benefits
+ Consulted to agree the objectives/goals of the project
+ Kept in formed of project’s progress
Consulted to validate and accept requirements
End User:
+ Helps defines the requirements
+ Highlight concerns of end users
SME:
+ Provides business knowledge to help identify, clarify and define business requirements
Project Manager:
+ Ensures project team adheres to the RE process
+ Helps to resolve conflict in requirements
+ Keeps the scope of the RE project under control
Tester
+ Helps define and validate acceptance criteria for individual requirements
Solution Architect
+ Responsible for the overall architectural design of the solution
+ Ensures architectural guidelines are met
+ Defines the technical constraints
