What?
Gathering requirements is very important, as they are a way of finding out what the new system should do, as well as make sure that your application supports the appropriate activities.
You are in constant communication with the customer, the users and developers, so that your system will match the users needs.
Failure of Software Projects
There are 10 reasons for a software project to fail, these are:
- Incomplete requirements (you should know this by now…)
- Lack of user involvement
- Lack of resources
- Unrealistic expectations
- Lack of executive support
- Changing requirements and specifications
- Lack of planning
- Elimination of need for the project
- Lack of management
- Technology illiteracy
When?
So, when should you gather requirements? The short answer is: ALWAYS! :D but most importantly at the beginning, else you’ll have no starting point.
So, why always? because requirements can change! The best way to avoid issues with requirements change is to not use the Waterfall process, but to use the Agile process – so that your users stay close.
Where?
Where should you gather requirements from? Well, nearly all requirements are gathered by asking the customers/users questions about what they require the system to do.
Look at the place of work, if they have lots of Post-it notes everywhere, then maybe there is some information on those, or maybe they would like to use the system to replace those post-it notes.
You could also look at the resources that are used in the task.
Refining Requirements
When gathering requirements, there is some structure to it. Such as asking questions, then from that you can make a Requirements Document and a Glossary. From that you can make a Use Case Diagram etc etc:
Kinds of Requirements
According to Ian Somnerville there are many kinds of requirements, these are:
Functional Requirements: Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.
Non-Functional Requirements: Constraints on the services or functions offered by the systems
Domain Requirements: Requirements that come from the application domain of the system and that reflect characteristics and constraints of that domain
User Requirements: Statements, in a natural language plus diagrams of what services the system is expected to provide and the constraints under which it must operate
System Requirements: Requirements that set out the systems functions, services and operational constraints in detail.
Presenting Requirements
once requirements have been gathered, they must be well presented. This is normally done in the form of a document commonly known as a Requirements Document.
Within it, it is normally split into a number of sections, such as sections for Function, Non-functional and User/Domain requirements.
No comments:
Post a Comment