Freefall: Requirements Analysis
Generally speaking, when all the requirements – or at least most of them – have been collected from stakeholders, next step is Requirements Analysis, when all the available requirements are processed in order to make them clear, complete, consistent and unambiguous, and resolving any apparent conflicts. [Wikipedia]
But in our case it is impossible to interview stakeholders, since the project sits on the assumption of the existence of a mobile network operator which is rather fictitious. Who should we interview? The only document given in our hands was the one we have called the “Problem Specification Document“. This document is the only artefact we are allowed to ask for clearing up any doubts. Pretty hard to ask questions to a document, huh? Here is the real challenge of Requirements Analysis: trying to resolve inconsistencies when no additional information sources are given. We’ll try to do it, however.
So, time has come to try making things clear once for all: it is recommended to spend a good amount of time on this step, trying to resolve the greatest amount of uncertainties as soon as possible; this way we are most likely to protect ourselves from time and effort loss due to late (when the project is already ahead with the development process) discovery of inconsistencies or – even worse – misunderstandings and errors.
Step 1: Requirements Grouping
During step 1, we group together requirements which refer to the same concept. This will help to roughly understand how many concepts are in play. In this step we still leave terms that we suspect to be synonyms as separated. This is not the time to refine our model. Depending on the problem size and complexity, this step shouldn’t take more than 20% of the total time reserved for Requirements Analysis, keeping in mind this is only an indicative measure given the simplicity of this task. Remember: this is only a preparation step.
Step 2: Requirements Refinement
The step 2 is the core of the Analysis: in this step, we unify the terms when in presence of synonyms, we explicitly define who or what pronouns refer to, in order to remove ambiguities (See “Price Plan” and “Tariff” in the document above, which were treated as equal in the one below: I’ve chosen to substitute “Price Plan” in sentences formerly referring to “Tariff” because I considered “Price Plan” more expressive than “Tariff”), we expand and contract sentences for clarity sake, and so on.
Step 3: Classes Identification
Once we have come to a clear, complete, non ambiguous list of requirements, during last step we identify Classes, which will be only some of our Entities in the Data Model. Each of these classes will hold part of the domain knowledge. It is important to point out that this is only a first, high level classification and that the final, actual taxonomy will take into consideration Object-Relational Database modeling techniques, in order to distribute that knowledge in a convenient way, as we will see the next time.
How do we identify Classes (Entities)? Personally, I use a powerful (though commercial) tool called Visual Paradigm, which lets you also perform Textual Analysis, among many other things. The process is quite simple: you paste your problem specification document and highlight all the nouns in there. Those become candidate classes. But how do you recognize a true Class from, say, an Attribute? Well, usually is quite straightforward the difference among these entities, since attributes are atomical entities whereas Classes usually need more than one attribute to live. Moreover, a wannabe-class may feel the need to exist during the entire system lifetime.
This 3-step process is the one I usually take to clarify what I am going to build. Now that we have a set of Classes, the next step will be that of building a taxonomy (UML Class Diagram or Entity-Relationship Diagram) which will hopefully pose some matters to solve which we will of course gain an even deeper comprehension of the problem.