| |
|
|
|
|
Common Problems & Consequences
|
Theoretically, at least, it's all rather simple. Firstly we need to understand the client's business and process for which the software will
be designed, then draw up the requirements and specifications, implement these blueprints and finally deploy the software.
|
|
|
Switch on, step back, and wait to be amazed. So why are there problems?
|
Clients know a lot about their business, but often less about how to investigate or communicate their needs in a design blueprint.
It's a difficult and non-intuitive process, there are a multitude of techniques and minimal guidance on when to use them.
|
|
What is a requirement, a specification, a use-case, a non-functional requirement?
|
|
Even if you have a knowledgeable partner, it can still be difficult to effectively explore and understand what will be delivered and whether that will be acceptable.
It's not hard to see why low quality requirements are the norm, and why these projects need lots of rework after deployment to make them usable.
Ideally you'd want an collaborative, interactive, step by step process that guides your requirements exploration and decision making.
This is exactly what eRequirements provides.
|
 |
|
|
|
|
|
