System Development Requirements - Report Example

Mochal (2008) and Davis (2009), presented some ways of gathring software requirements that are given below: Interviews According to (Oregon), Interviews are the most common and well-known way of colleting system development requirements. In this technique we form or develop a list of main questions that are necessary to gather the main system operational requirements. In this technique a face to face meeting is conducted with the person (user or customer) who can deliver us valuable requirements regarding the system development (Oregon). Strengths: Given by (Oregon) It is uncomplicated, for the reason that it needs minimum preparation. Less planning and scheduling required Less stakeholder dedication than huge workshops. Offers a prospect to look at or elucidate topics in more detail. Weaknesses: Given by (Oregon) The questions may imitate the interviewer’s defined ideas, which can change the responses. Time-consuming and unproductive for large number of stakeholders. Does not permit other stakeholders to perceive and give ideas upon the information being provided. Questionnaires Mochal (2008) outlined the idea of questionnaires regarding requirements gathering. According to (Mochal), questionnaires are more informal way of taking system development requirements. This can be helpful if the main person is not with us and is located at some distant location. By using this technique we can gather system requirements from huge number of people at the same time (Mochal). Strengths: (Mochal) Less time (same questionnaire for all) Multiple data sources Less costly Effort only once for preparing Useful for commercial projects Weaknesses: (Mochal) No quality information grantee Difficult to extract requirements from large number of responses Restricted response (only answers to specified questions) Prototyping Prototyping is one of the most recent techniques, which takes the requirements through a small solution that is performing some functionalities of large system that we are going to develop. We can say that, in this approach we use small version of real product. User views the small version and suggests next or better system operational needs (Mochal). Strengths: (Mochal) High quality and exact requirements extraction through better customer interaction More appropriate for large and sophisticated projects More appropriate when customer is not sure about requirements Weaknesses: (Mochal) Time consuming Lot of effort Costly to develop prototypes Survey Davis (2009), outlined another effective technique for gathering the system development requirmenst. In this technique we gather information and data from a large number of people. Here we can use close or open ended questions to take the response of people in any area of the system development. Here we survey the people through distributing questionairs that are filled up by them according to their point of view. It is not so much effective because every person has different opinion and thoughts (Davis). Strengths: (Oregon) Useful for huge number of stakeholders. Need less time for gathering large amount of data. Presents good results Excellent tool for statistical preference data. Needs less preparation effort. Needs less stakeholder dedication of time as well as effort. Weaknesses: (Oregon) Different people with different thoughts so less efficient results. Excellent trained and experienced workers are required for developing good surveys. Time for developing survey can be important. Needs further analysis in case of conflicts among stakeholders. Observation Observation is one of the most silent ways of gathering system development requirements. In this technique we gather system requirements through observing the people working in an environment for which we are going to develop the system. Here we observe the people and gather the system requirements. These are more generic requirements regarding the system development (Davis). Strengths: (Davis) Less cost Useful for large systems Weaknesses: (Davis) Time-consuming Low quality information Lot of effort because we need to observe all the users of system Document Analysis According to Davis (2009), in this requirements gaathering tool we review the system or operational structure’s current documentation to assess the main requirements. This is more complex way of gathering system operational regarding the system gathering requirements because it needs to understand the current system completely. Through this technique we can assess the main faults and difficulties in the system operational structure (Davis). Strengths: (Davis) Less expensive Suitable when system requirements respondents are not available Excellent tool for small projects Weaknesses: (Davis) Time-consuming No clear requirements Hard to verify system requirements Not suitable for large projects Use cases “A use case refers to a goal-oriented set of interactions between outside entities and the system under development. Entities are actors outside the system that interact with the system” (Bredemeyer Consulting). On the other hand, a use case can be defined as a method used in system study to recognize, elucidate, and systematize system requirements (TechTarget). Requirements gathering through use cases are a more standard and organized way. In this regard we gather the system requirements by caring out the detailed analysis of the system. Then we develop the use case that outlines how system will perform against any external input. Here system is checked for processing of any external input (Davis). Strengths: by (Swafford) Use cases avoid early design and spotlight on requirements. Use cases offer tractability. Use cases allow estimated and scheduled work. Use cases are simple to understand by the client. Weaknesses: by (Swafford) Not suitable for non-functional requirements. Present a learning curve for the developer and/or the client. Comparison of requirements gathering tools Requirements gathering techniques Time and cost Data quality People involved/responding audience Situation where implemented Interviews More time and cost High Only person who interview and interviewee When system respondents available Questionnaires Less time and cost Medium Large people involved When system respondents available or located at distant location Prototyping High costing and time High Main people who will interact the system Development of a sophisticated system Survey Less time and cost Medium Large people involved When there are huge users of system Observation Negligible cost but takes time Low All people working on the system are observed When we need to gather data in some operational mode/realistic data/regarding way of working Document Analysis Less cost but more time required Medium Only analyzer When no respondent available Use cases Medium time and cost High Person taking requirements and responding person When system development requires better user interaction Works Cited Bredemeyer Consulting. "Functional Requirements and Use Cases." 25 July 2006. Bredemeyer.com. 25 October 2009 . Davis, Guy. Requirements Gathering Techniques. 2009. 24 10 2009 . Mochal, Tom. 10 techniques for gathering requirements. 02 January 2008. 24 10 2009 . Oregon. Requirements Gathering Techniques. 2009. 24 10 2009 . Swafford, Steven. "Use Cases and Their Importance." 2009. ASPAlliance.com. 25 October 2009 . TechTarget. "What is Use Case?" 02 July 2008. TechTarget.com. 24 October 2009 . Read More