Wednesday, November 7, 2007

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

No comments: