Thursday, November 11, 2010

Use of Requirement Reports in SDLC

Requirements For A New System:
  • requirements report can be considered as a 'black box' - it specifies the inputs and the outputs together with ther relationship to each other.
  • however it makes no attempt to solve the problem.
  • when creating the requirements report the system analyst must be carefull to avoid reference and inferences that imply a particular solution. e.g. "the system shall operate continuously should a a storage device fail" is a better requirement than " the system shall include a RAID* (Redundant Array of Independant (or Inexpensive) disks) device where hard disks can not be hot swapped"
  • the second version specifies a particular solution and effectively rules out other possible solutions. the second version is likely to make little sense to the client.
  • the requirements report should be expressed in such a way that it is understandable to the client and also useful as a technical specification for the new system's developers.
How Requirements Reports are used during the SDLC
  • Requirement Reports are used to determine possible solution options and their feasibility.
  • The requirements report is a blue print of what the system will do, it forms the basis of the contract between the client and the system's development team.
  • it is a formal legal agreement, signed by both parties, the system is complete once all requirements have been met.
  • During the planning stage a particular solution and system development approach is chosen.  Updates are then included with specific detail about the selected solution.
  • During the design of the solution, teh overriding aim is to achieve all of the requirements specified in the report. commonly this involves the creation of various subsystems. each of these aims to meet specific requirements, however may originate from different areas of the report.
  • When implementing the new system it is necessary to decide on a method for converting from the old to the new system. The conversion requires participants to be trained on the new system. This highlights areas of partcipant interaction that training should address.
  • Testing and evalutation of the new system is all about checking that each requirement has been met. once all tests are successful then teh client, and the developers can be confident the sytem will meet its purpose.
  •  the requirements report must evolve to accomodate such modification to teh sysetm. it forms the basis for ensuring new modification do not replicate or affect the achievement of the existing requirements.

*RAID: a category of disk drives that employ 2 or more drives in combination of fault tolerance and performance. Theire used frequantly but arent generally necessary for personal computers. RAID allows you to store the same data redundantly (in multiple paces) in a balanced way to improve overall performance.
There are a number of types of RAID levels such as:
  • Stripped Disk Array without Fault Tolerance
  • Mirroring and Duplexing
  • Error -- Correcting Coding
  • Bit -- Interleaved Parity etc...
http://www.webopedia.com/TERM/R/RAID.html

No comments:

Post a Comment