4. Requirements Definition Flashcards
4.1 Requirements Engineering 4.2 Requirements Elicitation 4.3 Requirements Analysis 4.4 Requirements Validation (44 cards)
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
Outline 2 requirements estimating approaches.
Bottom-up estimation:
+ High level business requirements are broken down into functional/non-functional requirements, and then associated tasks to complete the requirement. Each task is then estimated for time and cost and then added up to get overall estimate for the project.
Rough order of Magnitude:
+ Experienced BA’s look at the PID and provide high level estimates and costs they expect for the project
4.2 What is tacit knowledge?
Tacit Knowledge:
+ The things that we know about but take for granted.
+ Things you know but don’t consciously know that you know them (unknown knowns).
+ The skill to do something without thinking about (unconscious competent).
4.2 Why is tacit knowledge a problem in business analysis and requirements engineering?
Stakeholders often fail to tell the analyst about things they either:
+ Do not know are important
+ Assume are obvious to the analyst which may not be the case
Results in missing requirements and not adequately understanding business context, processes, people and IT systems
4.2 What are examples of tacit and explicit knowledge?
Tacit
Individual:
+ Values
Corporate:
+ Culture
+ Organisational History
Explicit
Individual:
+ Job Description
+ Targets
Corporate:
+ Procedures
+ Manuals
4.2 Interviews
How would you plan for an interview to elicit requirements from a stakeholder?
Do background research on a combination of the following:
+ industry/sector - newspaper articles, business journals
+ organisation - annual reports, org charts, strategy docs, current issues in newspaper articles
+ department(s) - strategy docs, dept reports
+ offerings - descriptions, performance data, reviews, complaints
Decide who to interview and in what order
+ Reach out to someone e.g. project sponsor who can introduce you to key stakeholders
Prepare and distribute an agenda to interviewee
+ Who, What , Where, When, Why
4.2 Interviews
What is a good line of questioning structure to elicit requirements?
Context, Detail, Problem, Effects &Needs = Requirements
Context: ask questions for the interviewee to put their role/dept into perspective
Detail: ask questions to seek real facts and figures
Problems: ask specific questions about any possible problems that exist
Effects: ask questions to identify the problem’s effect and try to quantify them where possible
Needs: ask questions to identify what a resolution of the problem would look like
Requirements: The answers to the user needs is then documented as the requirements
4.2 Workshops
What are some benefits of workshops?
+ Faster: if info is required from large number of people
+ Ownership: of the results by stakeholders as they are involved in decision making
+ Consensus: stakeholders are involved in the decision making process which increases chance of achieving consensus
+ Quality: of decision making better as less chance of overlooking important issues
+ Wider perspective: stakeholders are able to see things not just from their individual perspective
