	André Leclerc	informatics consultant

A simple methodology for analyzing information management requirements

This page proposes a simple methodology for analyzing the requirements to be satisfied, or at least addressed, by an information system.

This methodology is based on some business modeling concepts that should be reviewed before continuing with the reading of this page.

What requirements ?
The requirements to be satisfied or addressed by information systems fall into three (3) categories, depending on whether they are: problems to be solved, opportunities to be seized, or constraints to abide by. In addition to being classified into one of the previous categories, an information management requirement can be further classified into one of the seven (7) categories below, depending on whether it is: a functional requirement (what needs to be done), a data requirement (what data needs to be managed), an operational requirement (how it must be done), a technical requirement (what technology must be used), a financial requirement (budgets), a timing requirement (deadlines and maximum durations), or a human-related or other special requirement. Requirements in the first two categories listed above are defined in the information system's business domain model (see a simple methodology for modeling the business domains of information systems). Operational requirements include requirements in terms of performance, availability, accessibility, useability, security and privacy. Technical requirements include requirements in terms of software, hardware, physical accommodations, and any other technology or piece of equipment that may be required. In addition to being listed in one or many categories, each requirement must be defined, qualified, quantified and prioritized, according to its relative importance within the organization sponsoring this analysis.

What requirements ?

The requirements to be satisfied or addressed by information systems fall into three (3) categories, depending on whether they are:

problems to be solved,
opportunities to be seized, or
constraints to abide by.

In addition to being classified into one of the previous categories, an information management requirement can be further classified into one of the seven (7) categories below, depending on whether it is:

a functional requirement (what needs to be done),
a data requirement (what data needs to be managed),
an operational requirement (how it must be done),
a technical requirement (what technology must be used),
a financial requirement (budgets),
a timing requirement (deadlines and maximum durations), or
a human-related or other special requirement.

Requirements in the first two categories listed above are defined in the information system's business domain model (see a simple methodology for modeling the business domains of information systems).

Operational requirements include requirements in terms of performance, availability, accessibility, useability, security and privacy.

Technical requirements include requirements in terms of software, hardware, physical accommodations, and any other technology or piece of equipment that may be required.

In addition to being listed in one or many categories, each requirement must be defined, qualified, quantified and prioritized, according to its relative importance within the organization sponsoring this analysis.

Back to opening page

Back to background material

Objectives
The main objectives of this methodology are to define all aspects of the requirements to be satisfied or addressed by information systems, to classify those requirements, and to specify them in enough detail to guide the definition and development of information management solutions, including information systems, that will satisfy or address those requirements.

Back to opening page

Back to background material

Scope
This methodology addresses the specification of requirements, but does not address the specification of informatics solutions or of information systems. That latter type of specification is the subject of another methodology.

Back to opening page

Back to background material

Approach
The steps taken to reach the objectives of this methodology are not as important as the objectives themselves. The end justifies the means. For that reason, this methodology only proposes a few simple steps that result in a detailed specification of the requirements. Any other approach that results in the same results or in similar ones can be used as long as the quality of those results is maintained. This methodology offers no further explanation or justification of this approach.

Approach

The steps taken to reach the objectives of this methodology are not as important as the objectives themselves. The end justifies the means. For that reason, this methodology only proposes a few simple steps that result in a detailed specification of the requirements.

Any other approach that results in the same results or in similar ones can be used as long as the quality of those results is maintained.

This methodology offers no further explanation or justification of this approach.

Back to opening page

Back to background material

Steps
The approach described above consists of the following four (4) sequential steps: Collect as much data as possible on the problems, opportunities and constraints that may lead to requirements (written communications, studies, reports, etc). Using the above data, devise a draft version of the requirements document containing tentative definitions, classifications, qualifications, quantifications and priorities. Review, correct and refine the contents of the requirements document drafted in the previous step with representatives of the organization sponsoring this analysis. This can be done via a mixture of surveys, interviews and group sessions. Produce the final version of the requirements document and present it to the sponsors of this analysis.

Steps

The approach described above consists of the following four (4) sequential steps:

Collect as much data as possible on the problems, opportunities and constraints that may lead to requirements (written communications, studies, reports, etc).
Using the above data, devise a draft version of the requirements document containing tentative definitions, classifications, qualifications, quantifications and priorities.
Review, correct and refine the contents of the requirements document drafted in the previous step with representatives of the organization sponsoring this analysis. This can be done via a mixture of surveys, interviews and group sessions.
Produce the final version of the requirements document and present it to the sponsors of this analysis.

Back to opening page

Back to background material

Epilogue
A good requirements document facilitates the communication of requirements and therefore leads to better requirement specifications. In turn, better requirement specifications facilitate the development of information management solutions to satisfy those requirements and therefore lead to better information management solutions. Finally, better information management solutions facilitate the conduct of business activities and therefore lead to better business results.

Epilogue

A good requirements document facilitates the communication of requirements and therefore leads to better requirement specifications.

In turn, better requirement specifications facilitate the development of information management solutions to satisfy those requirements and therefore lead to better information management solutions.

Finally, better information management solutions facilitate the conduct of business activities and therefore lead to better business results.

Back to opening page

Back to background material