C11 Documenting and Managing Requirements

Question 1

Why is it important to document requirements?

Answer 1

1) It enables communication within the project team an ensures related requirements consistent with each other.
2) the documentation provides the business managers and staff, who are sources and owners of the requirements, with a firm basis for validating that the documentation accurately records what they need the solution to provide.
3) Any further work to develop and test the business solutions will use the documentation as input to these activities.

Question 2

What sections might you find in a requirements document?

Answer 2

Introduction and background,
Business process models, 
Function models, 
Data models, 
Requirements catalogue, 
Glossary of terms.

Question 3

There are category types for requirements, what are they?

Answer 3

BUSINESS :

General - define business policies, standards and needs (Business constraints, policies, legal, branding, cultural, language).,

Technical - requirements that state the technical policies and constraints to be adopted across the organisation and and apply to a range of change projects (Hardware, Software, Interoperability, Internet).

SOLUTION :

Functional - form a key element of the requirements catalogue because they define the specific features to be delivered by solution (Data entry, data maintenance, procedure).

Non functional - concerned with how well the solution will operate. ( Speed of performance, level of security, access permissions, backup and recovery, maintainability, business continuity, availability, usability, accessibility, capacity).

Question 4

What are requirements driven by? and explain the hierarchy of requirements?

Answer 4

The organisations values, strategy and objectives.

The hierarchy of requirements is concerned with linking functional and non-functional requirements back to the general and technical business requirements, provides a means of tracing the original business needs for the requirements. This helps with considering prioritisation of the requirements, the timescale for delivery and the possibility of removing a requirement.

Question 5

In documenting a requirement, what elements might we consider?

Answer 5

• Requirement identifier - might include a version number,
• A short description that indicates what the requirement concerns.
• Requirement description - user stories - persona, verb phrase, object or noun phrase.
• Source - The originating person or the information source of the requirement.
• Owner - The business stakeholder who can make decisions regarding the requirement.
• Author - The analyst who ha elicited and documented the requirement.
• Type of requirement (general, technical, functional, non-functional).
• Priority - High / Medium / Low or MoSCoW.
• Business Area - The name of the business area to which a requirement belongs.
• Stakeholders - The people with an interest in the req (job role / names).
• Associated NFRs.
• Acceptance criteria - business staff to formally agree on how the requirement is to be delivered.
• Related requirements
• Related documentation (requirements document),
• Comments,
• Rationale,
• Resolution,
• Version history.

Question 6

The level of definition surrounding requirements will depend upon several factors, what are they?

Answer 6

• The stage of the analysis, is it an initial view of the requirement or more detailed requirements specification?
• The nature of the solution, for example, a business processs change or the IT system replacement.
• The level of priority of each requirement. This is an essential piece of information and will help prioritise requirements work. For example, if a requirement is given a ‘W’, the detailed work should be deferred.
• The approach to be adopted to deliver the solution, for example, evolutionary system development or off the shelf (COTS) purchase.

Question 7

What is horizontal traceability in relation to requirements?

Answer 7

Horizontal traceability concerns tracing the requirement from inception to delivery.

We can think about ‘backwards from’ and ‘forwards to’ traceability:

Backwards from - involves the ability to trace the source of the requirement from any later point in the business change or SDLC.

Forwards to - involves the ability to identify any requirement and track where it has been further developed and ultimately implemented.

Question 8

What is vertical traceability in relation to requirements?

Answer 8

Vertical traceability is concerned with tracing a requirement up and down the hierarchy so answers questions about alignment with business values, strategy and objectives.

Question 9

Requirements management is essential if there is to be traceability of requirements. Explain some of the elements involved in managing of requirements?

Answer 9

Requirements identification - uniquely identified;

Cross referencing - of req’s for elaboration / related;

Origin and ownership - the source of the requirement, and the owner is typically responsible for the business area affected by the requirement;

Configuration management - concerned with controlling any changes made to project deliverables, such as documents, in order to make sure that the changes are made in a disciplined manner and traceability is sustained.

Change control - documenting the proposed change -> consulting the stakeholders -> deciding on the change (full audit trail).

Software support - automated tools to help with documentation creation and storage, secure storage ad access, documentation linkage, version numbering.

Question 10

What can happen without proper configuration management? Requirements Management.

Answer 10

The requirements document can become inaccurate as the following problems can occur:

1) inability or difficulty in identifying the latest version of a requirement,
2) reintroducing out of date requirements,
3) using the wrong set of requirements for further development or testing of work.