I notice in discussions with clients that there is a great deal of confusion about the notion of requirements. I get quite careful when clients start asking "are the requirements done?", "do we have clear requirements"?
Same with terms as "Software requirements" "Specifications" "Business Requirements". When I ask a bit further, the definition, content and context of these terms differ per person, even in the same organisation. If Standish sees 'Clear Requirements" as one of the top-3 CSF's for projects, then it would be quite nice if we all know what we mean by that. How I love clear concepts :-).
Working with a client recently, we discovered together that their change processes were, well, somewhat messy. As change as a process is clearly an element in your BPM strategy: e.g you want to have control over this process as well!, we researched the painpoints in more detail.
One central thema - you guessed it - no shared language around the concept of requirements.
If we don't share the same language on the meta-concepts and the quality criteria around requirements, how would we even start to hope that we understand the requirements in itself?
What we came up with was a high level Requirements Framework, which defines requirement area's. The following diagram is useful:
It defines a framework of types/areas of requirements.
The area's:
1. Business Requirements. As in: requirements you put upon your business.
Strategic Goals & Drivers
These are statements about the intent and plans of the organization. 'Be number 1 in market XYZ, region ABC". "We sell to <target audience> through channels X, Y and Z". "We want to have an operating income of at least XXXX".
Product requirements
All the properties of your products (or services). And the rules of engagement - when are you willing to sell a product? What terms and conditions?
Information requirements
What information do you need when performing your processes? Per process? Per activity? What information do you produce?
How is this information structured? What rules apply (correctness, etc)?
What information is needed to steer your organisation and it's processes?
What information is needed from external stakeholders?
Process requirements
What processes do you need to exist? To serve your customers, deal with suppliers, produce products, steer processes and change processes? What supporting processes?
Which steps in a process? Inputs, outputs, link to goals, etc.
Organisation requirements?
How do you want the organisation to be structured? Which roles? Which authorities? What skill levels?
How many people?
2. Software requirements. As in: requirements you put upon your IT systems?
Functional requirements
WHAT does the application need to be able to do.
Non-functional requirements
Think URPS. Number of users to support, performance, etc.
Architecture requirements
Often put in the same area as non-functionals, but in fact very different. These are requirements from another stakeholder group, and need another area: what (mostly longterm) structures, practices, and technology standards do you require the application to comply with.
A number of notes:
- Each area has it's own value and it's own techniques & best practices to understand, formulate and document the requirements in the area.
- Areas are interrelated. Actually, most interesting requirements you will find on the borders: when performing process A to sell product B with information do we need when in step C. When performing process B, what functionality is required from the IT system?
- In each area you will find hierarchy in terms of detail. In process, for instance, a high level services overview, then drill down in process architecture, process activity flows, etc.
- Functional Requirements is the area that gets most attention. Typical techniques to document requirements in this area are "System Should .....", use cases, business rules documents, etc.
- Note that business rules are types of requirements you will find in more area's. In information: an customer can order multiple products in one order... In process: if insured amount > XYZ manual approval by role ABC is needed. Etc.
- You could call this complete framework "business architecture". I am always a bit carefull with "architecture", since that's an even vaguer concept. My objectives are to have a framework that evryone in a company can understand (and not some ivory tower group).
- The pyramid is also a great tool for knowledge management. If you work somewhere, these are the area's you should understand, to know your own role and added value!
Observation:
I think that methodologies that play a part in changing a business, including software development life cycle methods such as RUP, SDM, etc. should be innovated to methods that understand that requirements can be defined on multiple levels (e.g. system - as in organization and in software system) and that are able to integrate into these broader frameworks. This to prevent the earlier blogged about "task oriented applications" (see http://process-transformation.blogspot.com/2007/10/need-for-new-requirements-approach-and.html).
No comments:
Post a Comment