Collaborate and Communicate with Stakeholders to Clarify Requirements (validation) (7.5%) Flashcards
What is a Stakeholder?
Stakeholders - An individual, group of individuals or organisation with an interest (or affected) in the change.
Types of stakeholders
- Project
- Business
- External
Project Sponsor
The ‘owner’ of the new system
Responsible for ensuring that the system meets its goals and realises its benefits
Has sign off powers, budget authority
Has the final decision on all project matters
Accountable for the terms of reference
Initiates project reviews
Resolves project issues
Champions the new system
System End-Users and Managers
Represent the views of those who will use the system on a day to day basis
Make sure that functionality and usability requirements are properly specified
Must be happy that:
The requirements are workable
The requirements are complete
SME
The ‘super user’ who provides the specialist knowledge of the business area to be improved
Might be an external resource
May have ‘consultancy’ type experience
Provides information and ideas on business issues and possibilities
Works with the analysts to ensure that the knowledge and ideas are represented in the requirements
Project Manager
Plans and controls the project
Ensures the project keeps to time and cost constraints
Ensures the Requirements Engineering Process is followed
Resolves conflicts between stakeholders over the requirements
Business Analyst
The Requirements Engineers
Elicit, document, analyse, validate and manage the requirements
May assist in writing the User Acceptance Tests and run them with the users to ensure the requirements have been met
May produce supporting models such as process models, data models etc.
Developers
Responsible for creating the new IT system to meet the requirements
The developers’ main concern is that the requirements can be built and tested
Sloppy requirements will mean that the developers must constantly refer back to the analysts or simply ‘make it up’
Testers
Responsible for all testing elements from planning and specifying through to executing all necessary tests
Independence of testing from development is critical to ensure the quality of the product
Solution Architect
Responsible for designing the solution to the technical architecture
Defines the overall structure of the technical solution so that non-functional requirements will be met (including performance, security, and operating systems/ network/ database restrictions)
Customers
Are affected by the interfaces to the system (inputs, outputs)
Projects must comply with legal requirements concerning customers
Often need to communicate with them to inform them of changes
May need to consult with them to discover preferences
Regulators
Many industries have statutory regulatory bodies (e.g. financial, utilities, telecoms)
Regulatory constraints give rise to requirements on projects
So do changes in the law
Suppliers
May be affected by changes to interfaces
Will need time to change their systems if affected
Our degree of influence over the supplier will depend on (amongst other things) the relative sizes of the business
What do BA’s need understanding of to successfully elicit requirements?
To successfully elicit the requirements the Analyst needs to have an understanding of the:
business objectives
problem area
business processes in scope
systems supporting the processes
operational constraints and the business rules
stakeholders and their attitudes
We must also be sympathetic to the:
stakeholders’ needs
business change
possibilities of changing processes, structures, technology and so on
Why should we consider multiple stakeholder viewpoints?
Different stakeholders will have their own viewpoints on a requirement, and all may be valuable
Single viewpoint requirements may not satisfy other stakeholders and might yield unused system functionality
Multiple viewpoints help prioritise requirements
