Users can have lots of ideas about what they want their projects to be and where they want their projects to be lead to. The mind of a user is fertile resource of requirements, but the project team must focus the attention of the user to its most needed function.
the most difficult is not the act of recording what the user want, it is the exploratory, developmental activity of helping users figure out what they want.
The following steps are recommended by the book as those that we the project team should follow in order to accomplish proper requirements.
- Identify a set of key end users.
- Interview the end users
- Build a simple user interface prototype
- User paper storyboards if possible
- Develop a style guide
- Fully extend the prototype
- tread the fully extended prototype as the baseline specification
- Write the detailed end-user documentation based on the prototype
Create a non-user interface requirements doc
Identify a set of key end users
Localizing the correct user for the project is a very important part of the project plan, to identify this kind of user you must look for that that will be in contact with the software the most and will give you correct feedback about the kind of software they expect.
Interview the end users
Not much to say, its again, you must hear the end user and its needs, the project must be focused to fulfil what the end user wants. But the user is not very good at making correct architecture about its project and so we must look further than the user. but the user knows what he wants it to look like and so you can take proper information regarding what kind of interface to craft.
Build a simple user interface prototype
End users reaction first reaction after looking at the prototype.
Prototyping is all about how the result software will look. The point of this activity is to present many alternatives to the user before commit much effort to any approach. The project team must consist of a small group of senior developers that know how to make fast interfaces that give a feeling of comfort with the less amount of effort.
and make sure the user understand that the prototype is “just a prototype” otherwise expectations may rise or go down the drain.
This technic on this approach, developers and users gather together to draw on paper what they expect the and product to look like, they draw windows, buttons, etc. This approach is useful because the user can put some effort in making the prototype, it also helps at illustrating that a prototype is a small look of what the software must look and also avoid the team to over extends with the prototype.
On the other hand, some users are not very good at knowing what the prototype must look and this defies every point of the prototyping.
Develop a style guide
The developers should set standards for the look and feel of the application. This document should be at most 6 pages long where we describe things like where is the dev team placing the buttons. This is to create standards that lead the development of the user interface.
Fully extended prototype
The project’s vision statement enables developers to align their work in a general way; the detail user interface prototype provides the detailed vision that enables them to align their work in thousands of smaller ways. Here is a partial list of the functionality
- all dialog boxes.
- all graphical input screens.
- All graphical and textual outputs.
- Interactions with the operating system, such as importing and exporting data to the clipboard.
- Interaction with all third-party products.
Prototype as the baseline specification
The organization will base its estimates, plans, staffing, architecture, designs, and development work on it. It is both appropriate and necessary that the decision makes commit to the prototype and that changes to it be systematically controlled.
Write the detailed end-user documentation
The early development of the end-user documentation fleshes out the details of the software demonstrated by the user interface prototype, filling in gaps and flushing out inconsistencies.
Create a separate, non-user-interface requirements document
Specifications of detailed algorithms, interactions with other hardware and software, preformation requirements, memory and usage, and other less visible requirements can be recorded in a separate requirements document.+
McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.