Wednesday, November 14, 2007

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]

No comments: