The motivation for this page is to provide a (better) alternative to a template driven approach to requirements discovery and analysis. Templates encourage thoughtless box checking performance of work. A checklist is more lightweight and assist in developing an understanding of why particular information is sought, and how you might assemble and model the information.
Of course this page is both incomplete and riddled with areas that need improving. Please take the time to make at least a small improvement by adding, removing or improving this list. (And don't forget to discuss the content on the related Talk page.)
Policy Context[]
- What policy frames this initiative?
- What is the business motivation for the policy?
- What benefits are sought by the introduction of this change?
- Is each policy statement mutually exclusive ?
- Is the policy completely exhaustive ?
- Does the policy cover the whole area motivating the change?
- What other policies are linked or relied upon?
Useful Analysis technique[]
Create a Policy breakdown diagram (looks like an org chart diagram) and assess whether there is duplication or gaps when it comes to policy covering the ground for the motivation.
You’ll potentially model several policies this way if the problem area is defined by several policies.
Validation and risk assessments[]
- What unintended consequences might this policy present?
- What known negative impacts may this policy have?
- What risks do the gaps in the policy present?
- What risks does any duplication in the policy present?
- To what degree is there conflict or gaps across this and other policies?
What cross functional business processes support this policy?[]
- How many processes are there?
- What are they for?
- Who is responsible and who participates?
- What do they do?
- What inputs and outputs are involved?
- What transformations to information and things occur in the processes?
- What main pathways are there? What rules and decisions create these variation in process pathways?
Useful Analysis technique[]
- Each swim lane describes activities performed by a particular role
- Describe each process (ideally in 5-9 steps)
- Where this constraint doesn’t provide sufficient detail create swim lane diagrams for the sub processes
- Repeat this decomposition as needed.
- Create a hierarchical model (like an org chart or table) showing the relationships between the processes
- Describe (in text/tables) the inputs, transformation and outputs for each process step
- Describe the success criteria and failure criteria for each process step
- Success criteria and failure criteria are independent of one another
- Describe what happens when process steps fail
- Describe what happens when process steps don’t fail, but don’t succeed either
- Consider partitioning process steps by [1] role, [2] interaction, [3] motivation
- By interaction consider one event or interaction with a person and/or system.
- If something happens (or could happen across two different days or interactions then try dividing the process step into multiple steps.
Validation and risk assessment[]
- Is there a clear and unambiguous owner for each process?
- Does each process step contain verbs (action) and nouns (acted upon?) within their descriptions?
- Are all process step owners clearly known?
- Does each process model have a logical start place? Does each process model come to a logical end with the process initiator’s request fulfilled and validated?
- Where processes are handed off to other processes:
- Is there a feedback loop in place to ensure the handover was effective?
- Is the other process modelled and understood?
- Are all success and failure criteria known?
- What happens/should happen when things don’t fail, but also fail to progress?
- Are all process steps mutually exclusive?
- Are all necessary steps known, or are there leaps of faith or ‘magic happens ’ steps?
- Handovers from one role to another within the process model present likely areas for process breakdowns. What risks do you foresee at these points?
- What main ‘business terms’ have been identified so far?
Create a glossary of business terms being used.[]
A glossary will help remove ambiguity and start to define the data model.
Useful analysis technique[]
- Create a glossary in table form.
- You might like to create a set of reference items showing where the terms are used (e.g. policy goal, process steps, etc.)
- Pay particular attention to all nouns in the process descriptions for capturing entities and business objects (a jargon term for things that are handled)
- Also pay attention to all verbs which will indicate relationships.
- Cycle through this activity each time you decompose your models into lower levels of detail.
Validation and risk assessment[]
- Pay particular attention to verbs and nouns that are related to things handled in IT systems, paper forms and reports. Is everything covered?
- Consider whether you have covered the ‘system lifecycle’ for all the nouns in the system. How are they [1] created, [2] changed, [3] completed/deleted?
- Also consider when they are accessed for read only purposes.
- Have you updated your glossary at each level of detail?
What rules apply?[]
- Within the process steps you identified failure and success criteria. What Business rules drive those criteria?
- Within the process models you also described the transformations that occurred in each process step. What rules guide behaviours within the process steps?
- Within the process models you identified decision points where the work could flow down alternate paths. What rules drive those decisions?
- Who applies the rules?
- Who ‘owns’ the rules?
- Which rules can be appealed? And under which circumstances?
- (Review all verbs and nouns in your rules and add new ones to your glossary.)
Useful analysis technique[]
- Create a table for your collection of business rules
- Create attributes for rules as needed – you might for example capture its parent policy motivation, or the business owners for the rule.
Validation and risk assessment[]
- Are all the rules clear?
- Do any rules conflict with others within this policy context?
- Do any rules here conflict with business rules beyond this policy context?
- Are all process steps sufficiently supported with rules?
- To what degree is the application of rules duplicated in multiple places?
- Are these applications redundant?
- Can the processes be simplified?
- Can the rules be improved?
- Did new verbs and nouns emerge from your rules discovery activity?
- Do the process models need updating?
Interactions and scenarios[]
Commonly interactions are modelled via Use Cases . Simple use case models can help elaborate activities within processes. Unlike process models, interaction models are not necessarily sequential.
What you want to do is uncover the details of interactions within the overall system which you have captured via your rules lists, glossary, processes, and policy models.
Further details for rules, process, data and things in general are discovered.
Interaction requirements beyond process are also discovered. An example application is screen useability which generally can‘t be represented in process models.
Useful analysis techniques[]
- Use Case diagrams and narratives are particularly useful. So are other UML models depending on what details you want to flesh out.
- Mocked up screens or lightweight prototypes can help people better understand interactions when analysing and designing software.
- Narratives and storyboards give context and help focus models on context.
- Persona modelling helps understand the user as a human.
- Compare a temporary backpacker in the inner city versus a 50 year old mother returned to work in Albury as two personas within the role of ‘call centre worker, and the implications this has for system design.
Verification and risk analysis[]
- Can you trace each interaction model back to it’s context in the process models and policy?
- Are the interaction models independed of one another
- If not are the dependencies clearly defined and understood?
- Are new key words turning up?
- (Update your glossary and think about whether upstream models need revisiting.)
- Are all roles accounted for in the interaction models?
- Are failure modes accounted for?
- Are all steps in the process models covered?
- Does anything not ‘feel’ right?