If you want a good project, then you need to have good requirements. Having good requirements doesn’t guarantee that you’ll have a good project, but having bad requirements guarantees that you’ll have a bad project.
Project Inception
There is no one place that a project “comes from”. A new product/project (feature set) can come from lots of places:
- Sales people selling something (feature, product) that doesn’t exist
- Management gets an idea
- Marketing people seeing what competitors are doing
- Internal managers thinking about an internal need that needs to be solved
- Development team
We can Elicit a response from customers. (Ask them what problems they have, to try to get a solution.) This may cause scope issues, or feasibility issues. Clear communication is extremely important to be successful, since you may not have as much time to get a second chance to communicate.
At inception you should establish a basic understanding of the problem, who needs the problem solved, and the nature of how the problem will be solved.
At inception you may need to negotiate with your client/customer to get to a reasonable project requirement.
You should be working toward developing a specification. This term means different things to different people, everything from a graphical model to a written document.
While there isn’t a set definition, an organization should use the same methods through out their development teams, and should include some sort of natural language description and possibly include a graphical model/UI mock-up to reduce the chances of misinterpretation.
Requirements Engineering was originally found on Access 2 Learn
