Requirements management - further thoughts

(based on various discussions)

The focus is on requirements capture and working with business people that can lead as quickly as possible through to contract acceptance. The requirements will be capture in essentially the same way irrespective of how the solution is engineered (e.g. bought, customised, built/developed, assembled from an amalgam of bought/customised/built components). It is expect the requirements and the design (solution) will progressively elaborated (and related).

The model/reposiotory will:

• act as a hub or aggregator for many sources of data
• produce documents (word, PDF etc.) for different audiences often document unique to a time, purpose and stakeholder
• allow access to authorised users, any time/any where, via a broswer
• allow visual modelling and analysis
• allow requirements to be elaborated in design oriented modelling techniques as and where needed e.g. UML, ER, BPEL etc.
• allow requirements to be elaborated into acceptance and testing documents
• assign requirements to owners
• support requirements lifecycle
• support programme and project (e.g. allocate requirements to programmes, prohects, phases, SCRUM-sprints etc.)

Our approach to requirements management will record how Requirements relate to:

• Business drivers: goals, measures/KPIs, products/services etc.
• Business operations: interactions, functions, information, rules etc. (and will link to IRMs)
• Acceptance - criteria, plans, scripts, steps (repeatable, atomic, objective)
• Solution elements - as this allows us to understand impact and is the connection to work
• Programmes and projects - management and delivery work.

Our focus will be on Web portal interfaces, reporting (e.g. dashboards, PDFs, Word docs etc.), model analysis templates for requirements capture reporting now and the initial focus will be on 4 areas:

• Context - which will look at relationships in the context of business drivers and perspectives on business operation (communicate, do/function/process, decide/rules, know/information, technology feature)
• Acceptance - which will look at relationships elaborated through to Acceptance tests (more or less as per our Acceptance Management approach)
• Solution - which will look at relationships to solution elements (existing elements, OTS elements, developed elements, configuration etc.)
• Project - which will look at grouping e.g. into SCRUM lists; relationships to: Risks, Issues, Assumptions, Constraints, Changes

To start with I will focus on the top two areas and in short term I won't look at connection to an IRM, estimation etc. or data collectors, data extractor, or linking to other sources e.g. bug tracking (JIRA), document repositories (e.g. Team Rooms etc.) as this should be simple enough to add in due course.

Some properties that we will record about requirements are their: State/Lifecycle, Owner, Priority etc.

The expected use of the different elements of the solution:

• Web portal interfaces - are expected to be the main source of capture and review by most of the people on a project. [using Troux Explorer, Workflow]
• Reporting (e.g. dashboards, PDFs, Word docs etc.) - will be typically how information is presented (i.e. reports generated from the model/repository) [using Troux Intelligence]
• Collectors - will collect bulk information from existing electronic information e.g. XLS (Visio etc.), Idiom, Lattix etc. [using Troux Collectors]
• Extractors - will provide information for other systems [using Troux API]
• Model analysis templates - will mainly be used by power users for analysis, or for presenting diagramatic views for selected audiences and purposes [using Troux Architect]

Requirements management - some thoughts

(work on requirements management solutions)
[WIP]

I am focused on requirements for ICT systems in general.

There are a number of constituencies that need to be considered - i.e. people with different orientations. Their views need to be considered as they will provides insights into how requirements should captured, though the orientations are in technology domain not in the requirements domain e.g. :
- Functionally oriented - much development done in the 1970/80s was oriented around functional definitions of requirements
- Data oriented - who are focused on data models and databases
- Object oriented - as many modern general purpose development languages are OO
- GUI/Web oriented - as the systems is often defined by the UI, and RAD approaches are used for this
- Business process oriented - where workflows to define systems
- Business rule oriented - where business rules are key to defining systems
- Service oriented - where the systems are defined by their SI (systems interfaces) and orchestration.
- MDA oriented - where the goal is code generation via platform indendent models
- Microsoft oriented people - where the goal is code generation to a proprietary platform (i.e. with no platform indendence)
- Mobile oriented
etc i.e. there are lots of religious sacred cows in this area.

An approach to requirements management should demonstrate how Requirements relate to:
1 - How the business operates (interactions, functions/processes, information/data, rules, roles/parties) which will be the real world test of fit. This also allows industry reference models to be linked in.
2 - How the requirements are elaborated into definitive acceptance tests/scripts (repeatable, atomic, objective). As these are an expression of requirements.
3 - The solution and its solution elements (screens and/or UI elements, interfaces, reports, queries/searches etc.). As this allows us to understand which elements of a solution are affected by a change in requirements, and which elements are required i.e. expected to meet a requirement.
4 - Project management and delivery work.

What I am interested in is pure requirements capture that will work with business people - and can lead through to contract acceptance (irrespective of how the solution is engineered e.g. bought, customised, built/developed, assembled from an amalgam of bought/customised/built components).

Clearly the various ways of specialised modelling e.g. data modelling, object oriented modelling (e.g. UML), BP modelling, RAD/UI prototyping, etc. are useful. But they are design and designer oriented.

The requirements and the design (solution) is progressively elaborated and we need to avoid a gestalt problem e.g. where the "requirement" is defined using a "technology oriented language" e.g. referencing "objects" - when in fact the solution the implementation technology/strategy may not yet have been fixed. To use a non-IT example - if the technology was "masonry" - and mason may say an "arch" needs to be built, or a "lintel" installed - where are what is required is egress or access (perhaps a doorway).

The requirements management solution must:
- act as a hub for many sources of data (e.g. from many specialised modellers)
- produce documents (word, PDF etc.) for different audiences often document unique to a time, purpose and stakeholder
- allow access to details by any authorised user, at any time, from any where, via a broswer
- allows visual modelling of requirements
- allows requirements to be elaborated in design oriented modelling techniques as and where needed e.g. UML, ER, BPEL etc.
- allows requirements to be elaborated into acceptance and testing documents
- assignment of requirements to owners
- supports analysis of change over time, impact assessments
- requirements to project management (e.g. scrum concepts - to Product Backlogs, Sprints etc.)


RHE has invest a lot of time and energy in exploring most of the methods related to the various delivery technologies list above. RHE has also invested a lot of time and money in looking core enabling technology platforms that would enable a requirements management