Requirements In Context Part 8
This final article in the Requirements in Context series discusses detailed requirements for a fully automated business activity. ‘Fully automated’ means that the business information system (BIS) is expected to perform the activity from start to finish without user involvement. A simple example is the system automatically posting a monthly fee against customer accounts. A more complex example is the system utilizing customer-specific pricing details to determine the amount charged for a purchase made by a customer.
Within this series this type of system capability is called an automated function (AF). Like the other four capability types discussed in the previous two articles – user interfaces (UIs), reports, data imports, and data exports – an AF is a ‘unit of delivery’. Each should be represented by its own high-level requirement (HLR). That HLR becomes the context for detailed requirements discussions.
NOTES:
- Use of the terms ‘High-level Requirement’ and ‘Detailed Requirement’ are intended to correspond to the IIBA® BABOK® V3 terms ‘Stakeholder Requirement’ and ‘Solution Requirement’.
- Use of the term ‘discussion’ in relation to requirements is intended to imply any requirement elicitation technique.
- Use of the terms ‘Record’ and ‘Field’ is intended to be logical, not physical. The records and fields involved in an automated function may or may not equate to physical database tables and columns.
- Examples presented in this series are based on the Trips-R-You Flight Booking Case Study.
Business Activity Level of Complexity
The business logic involved in AFs can range from very simple to very complex. A simple activity is a candidate for full automation based on the need for it to be performed against a large number of instances. A complex activity is a candidate based on the cost and/or availability of staff with the necessary knowledge or skill level to perform the activity manually (or with partial support from the system via user interface).
NOTE: The justification for including the full automation of an activity within the scope of a project, including any organizational change management needed because of it, is outside the scope of this series.
Activity-specific Detailed Requirements
Types of detailed requirements for an AF address operational, record, and field details similar to those for data importing and exporting discussed in Part 7. Types of operational details relate to whether the AF is expected to run as a batch job or respond to real-time requests. Detailed requirements for records and fields depend on their involvement in one or more of the following roles:
- Input parameters
- Reference data available either within the system or through a real-time import request
- System records added, updated, and/or deleted by the activity
- Output parameters
- Specific error-related details
NOTE: How a BIS handles errors is a system issue. The business issue is what information business users need when a given type of error occurs.
In addition to operational and data-related details, an activity involving complex logic (i.e. a number of steps and/or decisions) should have that logic addressed as part of detailed requirements discussions. The objective is to understand and document how a trained or knowledgeable user would produce the intended results using input parameters and reference data that would be available to the AF.
Subject matter experts should confirm (i.e. sign off) the manual process description. Designers and developers should use the description as an aid to producing their deliverables (but not be ‘required’ to follow the process exactly as described). Testers can use the process description to develop test scenarios and test cases. They will need to follow the manual process to produce expected results for each test case involving a given set of inputs.
Flow charting is a well-understood form of representing a complex business activity graphically. As with any graphical representation, the labelled ‘shapes’ in the diagram should be accompanied by supplementary textual descriptions.
Use cases are another way to describe detailed steps of an activity. With a fully automated activity there would be no actor involvement in the steps or the activity’s initial triggering. An AF running as a batch job would be triggered by operational procedures. An AF operating in real-time would be triggered by some other capability (e.g. a user pressing the appropriate button that’s part of a particular UI capability).
The pre-conditions for the use case would be the availability (and validity) of values for the AF’s defined input parameters and reference data. Post-conditions would be the AF’s outputs – any output parameters or defined system records that the function is intended to add, update, or delete.
Complex Business Activity Example
The Trips-R-You case study includes an example of a business activity expected to be fully automated. The Finding Journey Options activity can be seen highlighted below in the project’s system context diagram:
The following HLR represents the AF capability unit of delivery:
“The system shall be able to identify the set of selectable journey options applicable to a given trip.”
The business activity to be fully automated is seen in the context diagram as being connected to the self-service Planning a Trip activity. Detailed requirements for the UI capability supporting this activity were discussed in Part 6. One of that UI’s screens supported sourcing details about a given trip. The fields needed as input parameters for the AF are:
- The preferred cabin class (e.g. Economy, Business).
- The number of adults taking the trip.
- The number of children taking the trip, their ages, and for any under the age of two, if they will need a seat or be sitting on a lap.
- For each journey within the trip, its ‘from’ and ‘to’ city or airport, and departure date.
One of that UI’s screens included a “Search” action element to initiate input field data validation and subsequent triggering of the automated activity.
The Finding Journey Options activity in the context diagram is also seen connected to an external Global Distribution System (GDS). This connection ended up as an HLR for a data import capability – triggered by the AF. Detailed requirements for that capability were discussed in Part 7. The data provided for importing from the GDS for each journey with a given trip includes:
- One or more flights scheduled on the designated date that allow the journey to be made.
- For each flight:
- Its current seat inventory and full fare for each cabin class.
- Any age-based discounts off the full fare for any cabin class.
Detailed discussions within the context of the HLR for the AF initially identified four manual steps:
- Get data from the GDS about scheduled flights to accomplish each journey.
- Identify which of those flights currently had sufficient seats for the trip.
- Identify the best available cabin class per flight.
- Determine the total fare for each flight based on traveller details for the trip.
At the end of detailed discussions, taking into account alternate scenarios and exceptions, the complete set of steps and decision points ended up as represented graphically by the following flow chart:
Had use case format been used instead of flow charting, the same steps and decisions could be represented as a main flow, three alternate flows, and three exception flows. The following diagram is a visual representation of those flows. The diagram only includes the individual steps within the main flow:
Both diagrams include unique identifiers for each element. Each ID corresponds to a supplementary textual description captured using the spreadsheet-based template for documenting detailed requirements for an AF. The spreadsheet includes is a specific worksheet for defining Activity Groupings (i.e. Use case paths or flowchart sub-processes) and one for defining Activity Elements (i.e. steps or decisions within a given Activity Grouping).
The details behind each identified group and element for the above example can be seen documented in the Trips-R-You Automated Function Example. That same spreadsheet also includes details of the operational, record, and field detailed requirements for this AF. With all details captured together as a unit of delivery, a single formal detailed requirement statement can be used to represent the set of detailed requirements for the AF:
The system shall be able to identify viable journey options based on the search parameters for a trip – as specified in DR18 – Finding Journey Options AF v1.0.”
Series Wrap-up
The objective of this series, as stated in Part 1 - Just Know it!, was to help business analysts improve their elicitation and documentation of functional requirements within the context a BIS.
Elicitation, using whatever technique, depends on knowing what types of information need to be elicited and to what level of detail. This series has strived to distinguish between high-level and detailed requirements and, within these levels, between types of information applicable to each of the five fundamental capability types a BIS is able to provide:
- User Interface (UI)
- Report
- Data Import
- Data Export
- Automated Function
A given BIS will support one or more functional areas within the organization and, within a given area, business processes involving business activities. These levels were discussed in Part 2 - The Functional View From 10,000 Feet.
The objective of a chosen solution to a business problem or goal may be to acquire or develop a new BIS, or to provide additional capabilities within existing ones. Identifying an initial set of candidate HLRs based on the stated scope of an IT-based solution was discussed in Part 3 - Scope = High-Level Requirements.
The objective of HLR discussions is to identify as many capabilities as possible that are expected to be in scope for the project (but not go into details about the needs within a given capability). This was discussed in Part 4 – Keeping High-Level Requirements High Level.
NOTE: Given an estimate of low, medium, or high for the complexity of each HLR, an initial (rough) estimate of the effort involved in delivering the capability and, thus the overall project, can be derived.
Capabilities involve data. Data maintained by a BIS may be sourced or updated manually through UIs or electronically through data imports. Or it can be derived by simple system functions or fully-automated activities. Data available in the system can be displayed for users in UIs and reports, output electronically through data exports, and referenced for deriving data or supporting fully automated activities. Data-specific detailed requirements, independent of its involvement with any number of capabilities, was discussed in Part 5 – Managing Data-Specific Business Needs Using a Data Dictionary.
Detailed requirements for a given UI or report capability include addressing its operational aspects. Requirements also include the fields involved being grouped and arranged in a reasonably-usable way within two-dimensional areas (e.g. a given screen or a page of a designated size). A UI has additional details involving navigation and action triggering. These details were discussed in Part 6 – Detailed Requirements for User Interfaces and Reports.
Detailed requirements for a data import or export capability similarly address operational aspects. But instead of fields being within areas, they are contained within appropriate records. When records of different types are involved in a given import or export, a set of record types may relate to each other in a hierarchical structure. Details for these two capability types were discussed in Part 7 – Detailed Requirements for Data Importing and Exporting.
Detailed requirements for fully automating a business activity were discussed in this article. Similar to the other capability types, there will be operational details and details about the data involved (fields within records, possibly in hierarchies). Depending on the complexity of producing the intended result, there may be a need to describe steps and decisions involved to manually produce the result.
NOTE: On completion of discussions of detailed requirements for a given capability, the original estimate of effort based on the capability’s HLR can be revised. Based on the detailed requirements, the estimates should be significantly more accurate and able to be given with a much higher level of confidence.
Ideally the detailed requirements for a given capability are captured as a ‘unit of delivery’ using a template or requirements management tool. The Trips-R-You case study examples have been documented using MS Excel capability type-specific templates. The resulting set of detailed requirements for each example is therefore contained in its own separate file. Given the details for a capability contained together as a set, a single detailed requirement statement (referencing the most recent signed-off file version) was used to represent the requirements for each capability.
NOTE: The concept of a single detailed requirement statement representing many individual detail requirements may appear strange at first. But there is a precedent for doing this – A fully documented use case includes numerous details about actions and fields involved in a given interaction between an actor and the system. The use case itself, including all of those details, is typically considered a single (detailed) requirement.
Series Take-away Points
- An HLR should represent one of the five basic BIS capability types – UI, report, data import, data export, or automated function.
- The signed-off set of HLRs represents the full scope of an IT-based solution to be delivered by a project.
- A detailed requirements discussion should be within the context of one or more HLRs.
- Detailed requirements for a capability should address the business operational and data needs specific to its capability type.
- When detailed requirements for a unit of delivery can be represented as a set, a single detailed requirement statement can be used to represent those details.
- Detailed requirements for records and fields (stored in or derived by a BIS) should be documented separately (e.g. in a data dictionary). Ideally the requirements management templates or tool supports referencing the separately defined system records or fields when involved in detailed requirements for a specific capability.
Series Conclusion
The term requirement means many things in many contexts. Hopefully this series of articles, combined with the Trips-R-You case study presenting end-to-end examples, has provided a clear meaning of the terms high-level requirement, detailed requirement, and requirement statement within the context of functional capabilities to be delivered in an IT-based solution.
This series began with a very old version of the 'Swings' cartoon, comically (but still accurately?) representing the stages of delivery:
The concepts presented in this series are intended to improve the primary business analyst deliverable: requirements. Given a complete and well-organized set of requirements, hopefully the follow-on steps in the process will result in the most business-appropriate ‘swing’ being delivered.
Author: Dan Tasker
Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].