Example - Requirements Engineering Process

In this section we will describe the effectiveness of requirements engineering process while gathering and analyzing requirements for a software system. This example with also

RG - Requirements Gatherer.
DE - Domain Expert
RA - Requirements Analyst
SAD - Systems Analysis and Design
SHLD - Systems High Level Design
  1. RG & DE &RA [Offshore] - 15 days before the start of the task all the SAD Experts will be asked to come out with the domain model of any similar system in that domain belonging to the proposed system. [we have a set of best practices meant for coming out with the domain model of a system ensuring that as much as possible the requirements should not get missed.]
  2. RG & DE &RA [Offshore] - This is where the domain expert and expertise is needed. This is all done and should be done offshore.
  3. RG [Onsite] - Requirements gatherer along with the domain expert should now be sent to the customers location with a clear idea about domain model and the functionalities to expect. Domain Experts job is to decipher the customers jargon in case the requirements gatherer finds something difficult to understand .
  4. RG [Onsite] - Finding the business stakeholders.
  5. RG [Onsite] - Finding the business Objectives and mapping it to the stakeholders.
  6. RG [Onsite] -Finding the out the top level systems needed from the business stakeholders.
  7. RG [Onsite] -If possible prioritize the systems and subsystems.
  8. RG [Onsite] - Find out the context , actors and the behaviors.
  9. RA [Offshore] - Prepare the Usecase diagram based on the information gathered.
  10. RG [Onsite] - If possible prioritize the functionalities.
  11. RG [Onsite] - Find out the top level details of the prioritized functionalities.
  12. RA and DE[Offshore] - Prepare the top level Usecase document for each behavior.
  13. RG [Onsite] - Find out the information related to the domain model.
  14. RG [Onsite] - Find out all the core domain entities.
  15. RG [Onsite] - Find the types of each core domain entity.
  16. At the end of every day the RG team is supposed to send the gathered requirements back to the offshore team so that they can analyze and model the gathered information and cross check with their reference models, best practices and systems. Any information gathered should be analyzed by the analysis team and any questions to be asked or clarification should be send to the requirements gathering team along the analysis model.
  17. RG [Onsite] - Start capturing various non functional requirements from the customer mapping the same to different behaviors and subsystems of a system.
  18. SHLD [Offshore] - If designing is also outsourced , then at this stage then the offshore system designer can start evaluating various non functional constraints and start coming out with various solutions clearly documenting the pros and cons of every design solution. [This task will happen in parallel with the analysis activity].
  19. SHLD [Offshore] - For any unknown part if any prototypes need to be developed , then those prototypes can be developed and tested as well. This task can happen in parallel with the analysis stage. [This task will happen in parallel with the analysis activity]
  20. RA and DE [Offshore] - Find out any core domain entity which is not present in using the reference models and other sources like internet .
  21. RG [Onsite] - Verify with the customer in case of any ambiguity or confusion .
  22. RA and DE [Offshore] - Find out any core domain entity types which is not present in using the reference models and other sources like internet .
  23. RG [Onsite] - Verify with the customer in case of any ambiguity or confusion .
  24. RA and DE [Offshore] - Find out the relationship possible between core domain entities without missing any relationship using the DSM.
  25. RG [Onsite] - Verify with the customer in case of any ambiguity or confusion .
  26. RA and DE [Offshore] - Find out the details of each relationship in coordination with the onsite team.
  27. RA and DE[Offshore] - Come out with a structural model of the system in such a way that the entire structural complexity of the system can be visualized in a single frame of vision insuring that the figure is highly understandable and highly flexible as a well.
  28. RA and DE[Offshore] - Given the functionalities suggested by the customer , looking into the structural model find out if there are certain behaviors which look obvious from the model but is missing in the customers requirements.
  29. By this stage we will actually have a good understanding of the actual complexity of the system.
  30. RA and DE[Offshore] - For certain important domain entities and systems use diagrams and features provided by the system to find out any missing behaviors.
  31. RA and DE[Offshore] - For the top level behavioral requirements already fed into the system , use the validate algorithm of the system to check if something aspects are missing in the requirements.
  32. RG [Onsite] - For every behavior find out the core domain entities to be manipulated .
  33. RA and DE [Offshore] - For the top level behavioral requirements already fed into the system , use the validate algorithm of the system to check if something aspects are missing in the requirements.
  34. RA and DE[Offshore] - Using the algorithms of the system find out all the possible logical scenarios within a particular behavior by supplying the domain entities and its type to the algorithm.
  35. RA and DE[Offshore] - Put all the possible logical scenarios for a behavior in a word doc and send it to customer as a formal email asking him to mark which scenario is possible or valid and which scenario is not possible for invalid. Also put a disclaimer in the mail that for any scenario for which he says invalid today... will be considered as a change request which will be a payable change.
  36. RG [Onsite] - For every scenario for which the customer says valid , ask him to prioritize.
  37. RG [Onsite] - For every scenario which the customer puts on the 1st 2 levels or priority, now ask him for the business logic for each of the possible scenarios.
  38. RA and DE [Offshore] - For every logical scenarios of a functionality for which the business logic is captured, the analysis team is supposed to come out with detailed Usecase. They are also supposed to come up with a flow chart or activity diagram for every scenario.
  39. RA and DE[Offshore] - Using the system also generate the detailed test cases for testing every scenario.
  40. UI Designer [Offshore] - Prepare the UI Mockups for every behavior.
  41. RA and DE [Offshore] - Append the UI Snapshots to the detailed use cases and the send the same along with the test cases for customer validation.
  42. Note- Both detailed Usecase and test case will be in a form that any layman can understand. Also put in an email
  43.  SHLD [Offshore] - Propose the various design solutions to customer clearly documenting the pros and cons. Make them choose a particular design solution.
  44. RG [Onsite] - Get the use cases reviewed and validated by the customer .
  45. RA and DE [Offshore] - For any changes expected by the customer, quickly make the changes, validate and again send it to the customer so as to complete the feedback..
  46. RA and DE [Offshore] - Once the use cases are validated by the customer prepare a formal SRS documenting both the functional and the non functional requirements of the system and get a formal closure on the same.
  47. SHLD [Offshore] - Once a particular design solution is accepted by the client. Come out with the detailed system level class diagram by adding the classes representing various design elements to the domain level class diagram from the analysis stage.
  48. SHLD [Offshore] - come out with a detailed system level class diagram deciding on the attributes and methods of each class.
  49. SHLD [Offshore] - Come out with package, component and deployment diagram for every system.
  50. SHLD [Offshore] - Now modify the business level Usecase from the analysis stage and come out with system level use cases with the design elements incorporated within the same.
  51. SHLD [Offshore] - Describe every scenario of a Usecase to be codified by a implementer by a sequence diagram.
 
Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer

www.VPlanSolutions.co.in