Dan Tasker

Dan Tasker

I recently retired after working and consulting in the IT industry for 48 years. I spent the first 10 years working as a developer (called ‘programmer’ back then) in the United States and Canada. This was followed by two years teaching computer programming, database design, and data modelling. The remainder of my career was spent as a business analyst, in Canada, Australia, and New Zealand. I continue to be passionate about quality requirements and helping business analysts produce them. I can be contacted at [email protected].

 

The Problem

A project chartered to deliver an IT-based solution typically begins with establishing high-level functional requirements (HLRs) which are eventually followed up with detailed functional requirements (DTRs). The problem is that there have never been clear guidelines for what constitutes ‘high-level’. And when it comes to DTRs, there are no guidelines for how much detail there should be in a given requirement statement, making it difficult to check for overall completeness and/or redundancy.

The Solution

The solution to the HLR problem is to recognize that there are five fundamental capability types for adding domain-specific functionality on top of a data management capability. A given high-level functional capability should be viewed as one of the following:

  • A Report
  • A User Interface
  • A Data Import
  • A Data Export
  • An Automated Function (e.g. ‘batch job’)

A given HLR should only identify who it is that needs a specific one of those types. A properly high-level HLR should contain no ‘field-level’ details.

The solution to the DTR problem is to recognize that for each of the above five types, the necessary detail can be captured in a ‘structured’ format rather than in textual requirement statements. A single DTR, containing no more detail than its corresponding HLR, should be sufficient as an aggregation point for the capability’s structured details.

The RIC MDG Technology provides that structure. It extends the Enterprise Architecture concept of Requirement, and adds additional stereotypes to capture the detail.

The Trips-R-You Web-Based Flight Reservation System case study shows examples of HLRs, DTRs, and spreadsheet-based templates structuring the example details for each of the five capability types. The RIC extensions are described in the article Tool Support for Requirements [In Context]. Documenting functional requirements for an information system-based solution using Requirements In Context format is described in detail in the Requirements In Context Series of Articles.

 

NOTE: Any questions or problems with the RIC MDG Technology please contact the author.