Introduction
Although most companies do some form of requirements, there is often a lack of understanding to understand exactly why the requirements need to be created and the level of detail that should be included in the requirements.
The software is always created to solve a need for a client. The client can be an internal client, an external client, or even the general public. The detailed requirements are important to ensure that a program correctly and fully meets customerneeds.
Detailed requirements to make the initial development easier and faster because the developers know exactly what they should be developed and does not need to do their best to guess which features to implement or delay development by creating requirements during development. Giving the developers accurate requirements will also lead to less rework at the end of development, because the needs of stakeholders who will have been implemented correctly and will not initially come tothrough trial and error.
A project manager can use the detailed requirements to create accurate timelines and give correct estimates to the customer. This ensures that stakeholders are fully aware of how long the development will enable them to adjust the scope of a project or proactively add resources if necessary.
Finally, testers can use the requirements to create test plans while development is ongoing, rather than waiting until development is complete. The requirements to give theminformation on what the program will there can be disputes between developers and testers as to what the capabilities of the program should be. high-quality requirements also describe the paths problem that may need further testing.
Although highly detailed requirements make it easier to develop in the later stages, this is not always possible due to time constraints imposed by the customer or market conditions. With this in mind, let's look at some secrets to improve your needsprocess even under tight deadlines.
Secret # 1 - considering the cases in the U.S.
Use cases to examine the requirements from the perspective of an end user working with the program and how the program responds to user input. At its simplest level, a use case can be thought of as a game in which the end user is an actor and the program is another actor. These two actors then have dialogs which explain the interactions among the actors. More complex scenarios may have other actorsincluding programs, other types of users, as well as hardware. Use cases have proven to be very easy to read and understand, even for non-technical customers.
Each use case explores what happens when something goes wrong in addition to "normal" interactions. The exploration of these error conditions is very important because these cases are more difficult to code and may cause the greatest number of tests. Traditional requirements often ignore these cases. It may be usefulare developers and testers both think of additional possible failures in a use case so that they can be fully documented in the requirements.
Use cases do not provide a complete picture of the system though. A technical specification should be included in the requirements for the details of the formulas and procedures that take place behind the scenes.
Secret # 2 - Prototype Screens with a Design Tool
A user of the program interacts only with a program through the user interface so that it makes sense to spend a considerable amount of time requirements to ensure that the user interface makes sense, all the functionality that is included, and that the most commonly used functions are easily accessible. The easiest way to do this is using a prototype of the screen.
There are a variety of methods to screen prototypes, ranging from simple interface design with a pen and paper to building "working" prototypes in a high-level language such as Visual> Basic which allows rapid screen design. However, each of these extremes has serious drawbacks. A prototype pen and paper does not allow users to interact with the prototype and is more difficult to change. A working group of "prototype" done in a programming language like Visual Basic can lead the customer to believe that the program is almost complete and that the development should not take much time or can lead customers to believe that changes to the prototype will be expensivewhich makes them reluctant to provide necessary suggestions to improve the program.
Between these two extremes lies screen design applications that let you design the screens and interactions between the screens of the model. High quality prototyping tools allow you to enter sample data and allow users to navigate between screens by pressing the buttons so that they can easily understand the interface and functionality. Most of the prototyping tools produce the final output in an HTML format so they can be easilyshared even if a customer is not in the same office where the requirements are being developed.
When looking for a prototyping tool, make sure you select a tool that is fairly easy to use, you can easily prototype screens, while the customer is in the room. This will allow you to brainstorm and to make changes to the screens without delays. A prototyping tool should already have common controls already defined to maintain design standards and improve the appearance of the screens. Being ableto enter the sample data in each screen can allow the customer to identify areas that can be corrected.
Secret # 3 - work directly with end users
When designing a new application or make revisions to an existing application, there is no substitute for direct experience that end-users. The end user can give immediate feedback on your design to highlight the functionality awkward or incorrect. They also help to ensure that all controls are logically placed for the mostefficient use of the system.
Using an interactive prototyping tool allows you to walk a user through the interface or even allow them to work directly with the prototype so that they can quickly suggest improvements. As use cases are under development, is a good idea to accompany the user through the case to ensure that the use case is well thought out and that all functionality is captured in both the use case and prototype.
Secret # 4 - Requirements iterativeDevelopment
When creating the requirements, it is important to develop the requirements in stages. For example, you may decide to have a general layout of the program and create higher level use cases in the first session to get a feel for the overall requirements. In the following session (s), you can focus on each key feature to ensure that the normal paths are all defined in use cases and further refine the prototypes. In the following session (s), you groped to define all theerror conditions that may occur and update the prototypes as necessary. The final session should review all the work previously done to ensure that all requirements are clear and complete. At each stage, you should not be afraid to review the work done in a previous step because getting the requirements correct will ultimately save time in development more expensive and testing stages.
Secret # 5 - Point requirements documents under change control
With all the time spent ongeneration of clear requirements, is very important to ensure that all documentation requirements are included in the system of exchange control. This includes use cases, screen prototypes, technical specifications and other documents used to define the requirements.
Conclusion
In this article, we explored various secrets to make your needs success of the process and ensure that customers are satisfied with the resulting program, even under tight deadlines.At the beginning of your next project, make sure you have the right tools to keep a successful requirements iterations including a prototyping program, a tool to write use cases, and a program of version control. These tools should not be expensive, and that will help you get your requirements right and schedule under control.
No comments:
Post a Comment