In Part 4 we drew both high level and low level versions of the To Be model of our customer’s change control process, based on the information we noted in Part 3.
We are now ready to drive out and document high level system requirements (HLSRs). It is these requirements that will form the scope of the system development project.
Armed with the To Be model and the customer’s strategic goals, there are two approaches you can take to eliciting the HLSRs. You can be more passive and let the customer drive the requirements out while you validate them against the To Be model and the goals. Alternatively, you can be proactive and produce a set of candidate requirements based on your understanding of the To Be model and have the customer validate them. Your choice of approach will depend on your level of skill and experience as well as the nature of your relationship with the customer. If you find that you or others are fretting over which approach to take, just pick one. All rivers lead to the sea, after all.
Remember that our first strategic goal stated:
- All workflows will be automated where it is felt the return on investment will result in cost savings.
This allows us to drive out the first requirement:
HLSR-001: The solution will provide an automated workflow for the handling of change requests.
This requirement seems so obvious that it hardly seems to be worth documenting. After all, the rest of the requirements all relate to a workflow, right?
True, but it is important to get into a habit of documenting things even if they seem obvious to us. Bear in mind that the HLSRs will be read by people who might not have taken a look at the business analysis. HLSR-001 unambiguously sets the context of the requirements at first glance.
HLSR-001 does not address the issue of return on investment. Once the project scope has been decided, tenders will be invited from solutions providers. Once the cost of the solution has been estimated, the issue of ROI will be decided and the project will get the go-ahead (or not).
The next two strategic goals stated:
- In workflows, and where possible, decisions will be made automatically by the workflow system based on pre-defined business rules, rather than user whim, in order to ensure consistency in business practice.
- In workflows, and where possible, pre-defined business rules will be maintainable by the business, in order to ensure flexibility in the business model.
We can use mostly the same words for our next two HLSRs:
HLSR-002: Where possible, workflow decisions will be made automatically by the system based on pre-defined business rules in order to ensure consistency in business practice.
HLSR-003: Where possible, pre-defined business rules will be maintainable by the business, in order to ensure flexibility in the business model.
We now look at our To Be model and identify more requirements that relate to the solution as a whole, rather than specific steps within our change control process. This should be easy because we have used different shapes to indicate user steps that are to be aided by the system, fully automated steps where the system assigns tasks, and other fully automated steps. This allows to quickly spot the next requirement:
HLSR-004: The solution will allow the automatic assignment of tasks based on either pre-defined roles or user selection.
Automatic notifications are a key feature of the To Be process.
HLSR-005: The solution will incorporate e-mail notifications. Notifications will be pre-defined and automatically sent at certain points in the process.
Now that we have documented requirements for the key features of the solution, we must define requirements which bring the functionality into scope. This is important because if we leave out a key area of functionality from the scope, the estimated cost will not include it. Later, when it is realised that something is missing, the scope will have to be expanded and our costs and plans changed.
We use the top level view of our To Be model to identify the key functional areas. However, we must also check the lower level Sub Processes, because they are likely to suggest functional requirements also.
We must be discerning here. Some of the steps within the process might translate into high level requirements. Others might belong among the low level requirements. The skill is in providing requirements that establish the scope of the solution with sufficient definition to allow meaningful costing, and scheduling but also with sufficient flexibility to allow the low level requirements analysis to investigate various possibilities.
The key functional requirements that come out are:
HLSR-006: The solution will allow users to submit Change Requests (CRs).
HLSR-007: The solution will allow users to review CRs.
HLSR-008: The solution will allow users to log any outcomes of CR reviews.
HLSR-009: The solution will allow users to assign CRs to specific users.
HLSR-010: The solution will allow users to log impact evaluations against CRs.
HLSR-011: The solution will allow users to log that project-related plans have been updated (e.g., Project Plan, Release Plan).
HLSR-012: The solution will allow users to log that changes have been applied.
HLSR-013: The solution will allow users to log verification results.
HLSR-014: The solution will allow users to log that products have been released.
Other functional requirements may come out that do not feature on the To Be process model, such as:
HLSR-015: The solution will allow users to search for and view resolved CRs.
Notice that we say “users” all the time when we know the roles. We do this because it means we don’t have to list all the roles to which a particular requirement might apply and because what we are trying to define here is the basic functional capability of the solution. Stating the specific role at this high level adds no value. However, the roles will be important at the lower level detail of requirements.
Of course, the HLSRs will also contain non-functional requirements (NFRs), some of which will already be defined at a corporate level (performance and security requirements for example). Others will be specific to the current process (user volumetrics, for example). We will not go into specific examples here, as this is a process exercise.
Once the high level system requirements have been defined, the scope of the project is established and this allows our customer to choose a technology, the solutions provider and the methodology (based on tenders). Once these have been decided, the development project can begin.
Up to this point, we have in a sense been taking a waterfall approach. We established our To Be business process (although we may have done so iteratively) and only then did we investigate and document the HLSRs. Only when that is complete can technology, provider and methodology be chosen and once these are in place, development can begin. I would hope the customer would choose an iterative methodology. In fact, for a workflow solution using a tool like Pegasystems‘ PRPC, I would be shocked and dismayed if they did not.
In Part 6, I will show you how we can use the HLSRs and To Be process model to build our workflow model. If you have not already read the series of posts on drawing workflows, then I suggest you do so before reading Part 6.
Leave a Reply