Please enable JavaScript.
Coggle requires JavaScript to display documents.
Requirements engineering - Coggle Diagram
Requirements engineering
The standardized approach to defining requirements using set techniques and guidelines that everybody can use. The bsais of Requirements engineering involves: Frameworks, techniques and standards.
Framework
Requirement elicitation Setting out and discovering what the actual requirements are depending on project circumstances.
Techniques
Interviews to gain useful information from stakeholders which in turn builds relationships - this can also bring out sensitive issues due to the closed format.
Workshops they take less time than interviews and promote collaboration. Workshops should be well controlled and involve the right people that follow a set list of objectives.
Focus groups are specialised workshops designed to focus in on the views and opinions of participants - this will involve questions followed by group discussion that can help with non-functional requirements.
Observation sometimes best to watch users perform a process in order to understand the real world use of a system. This method can be skewed as people sometimes change approach during observation.
-
Scenarios often used in the interview process and poses a situational ask such as "What happens if a customer phones to cancel an order after the
delivery van has left?" - this can outline process difficulties.
Prototyping sometimes a prototype will help to spark imagination and can outline users opinion on an early product. Prototypes within IT can often develop and become the final product.
Questionnaire / Survey opens up geographically dispersed opinions that could be based on local opinions and will offer data required to support a project.
Document analysis is checking the existing source to outline what would be required within a new system for data models.
Record searching to help with quantitative data about the expected situation of a system - For example how many cars are sold per month.
Activity sampling is a sample of how users are spending their time but as this is observation users can find this process unnerving.
Requirement analysis after elicitation it is important to methodically check requirements to validate they meet standard and can also create more work to meet the standards.
Good requirements
-
Relevant is the requirement in the scope of the project? - anything falling outside of relevance should be passed through a sponsor.
-
-
Understandable is the requirement known and understood between stakeholders such as who the 'Customer' is.
-
Consistent requirements should have no conflict such as Secure vs Accessible. Inconsistencies need to be removed for success.
Owned each requirement should be owned to make sure each requirement is met correctly by somebody who can make a decision on content.
-
-
Concise to meet quality criteria a requirement needs to be as brief as possible for easier understanding.
-
-
Conformant does the requirement meet organisational policies and standards such as how things are documented or handled?
Requirement validation is the sign off of requirements and can decide the "build or buy" or a project.
Verification making sure the product has been made correctly and conforms to outlined standards and requirements for the product - has everything been done correctly?
-
Requirement documentation throughout the first three stages everything is documented to represent the functionality.
Requirements catalogue
-
-
Version / Status the version plus it's status (draft, signed-off etc).
-
-
-
-
-
-
-
-
-
-
-
-
Requirement management the management of requirements set out and the prevention of "scope creep", this also involves tracing back to the source for resolution.
Configuration management knowing the current status of a requirement and documentation such as controlling the version of a document.
Change control the process of documenting proposed changes and their impact on project scope, cost and timescale ti implement.
Traceability the importance of being able to trace requirements to their source to forward their resolution. After implementation it can be useful to know 'why' something was implemented.
Roles
Project sponsor The person(s) accountable for delivery of business benefits. The sponsor will make the final decision on key stages in a project and sign off on the business requirements.
Managers have an input on the overall requirements process (potentially owners of individual smaller requirements) - They will share views and needs.
Users are the process workers who will hold valuable information about the current process and should be kept onboard to prevent disappointment with the finished result.
Domain experts are experienced consultants with an outside view of the organisation often able to provide prior experience, often domain experts are used for alternative views on methods.
Project manager is focused on key milestones and deliverables throughout development. The project manager sometimes also keep tabs on project scope.
Business analysts hold the responsibility of Eliciting, Documenting and managing requirements of the project / business.
-
Developers should have a clear understanding of the project scope and requirements of which to work from. Developers should be consulted with during requirements engineering. Developers can also hold responsibility for gathering additional requirements detail from users.