OVERVIEW OF THE REQUIREMENTS DEVELOPMENT PROCESS

• Identify a set of key end users who collectively have the credibility to define the software that the team is building.
• Interview the end users to create a set of preliminary requirements.
• Build a simple, interactive User Interface Prototype.
• Show the simple User Interface Prototype to the key end users and solicit their feedback. Continue revising the simple prototype, keeping it simple, showing it to the end users, and revising it again until the end users are excited about the software concept.
• Develop a style guide that codifies the prototype’s look and feel, review it, and put it under change control.
• Fully extend the prototype until it demonstrates every functional area of the software. Make the prototype broad enough to cover the whole system, but keep it as shallow as possible. It should demonstrate the functional area, not actually implement it.
• Treat the fully extended prototype as the baseline specification. Put it under change control. Then require the developed software to match the prototype exactly except for changes approved through the change control process.
• Write the detailed end-user documentation based on the prototype. This detailed end-user documentation will become the detailed software specification, and it should also be put under change control.
• Create a separate, non-user-interface requirements document for algorithms, interactions with other hardware and software, and so on. Put that document under change control.

A project team, no matter what size, needs to differentiate among the various roles played by team members. On small projects, several roles may be performed by one person.

Project manager
The project manager is responsible for orchestrating the detailed technical work of the project, including development, quality assurance, and user documentation. The project manager is responsible for developing the project’s software development plan and is usually the development team’s link to upper management.

Product manager
The product manager is responsible for integrating project work at the business level. On commercial software products, this work includes marketing, product packaging, end-user documentation, end-user support, and the software itself. On in-house projects, this work includes working with groups that will use the system to define the software, setting up training and user support, and planning for cut over to the new system.

Architect
The architect is responsible for the conceptual integrity of the software at the design and implementation level.

User-interface designer
The user-interface designer is responsible for the conceptual integrity of the software at the level visible to the user. On in-house projects, this role can be played by someone from end-user support, user documentation, development, or product management. On commercial products, it should be performed by a user-interface specialist.

End-user liaison
The end-user liaison is responsible for interacting with end users throughout the projectwalking them through the prototype, demonstrating new releases, eliciting user feedback, and so on. This role can be performed by a developer, product manager, or someone from end-user support.
Development Lead
The development lead is the mid-point in the path between being a developer and being the solutions architect. They are still rooted in the reality of the code and the capabilities of the developers they have working on the project. They were once developers themselves and instead of spending all day every day coding their own tasks they now lead and mentor developers as the developers have problems that they don’t understand.

Developers
Developers are responsible for the detailed design and implementation of the software. Developers are responsible for making the software work.

QA/Testers
The quality assurance personnel plan and manage test activities, create detailed test plans, and perform tests. They are responsible for finding all the ways to make the software break. If the project is large enough, these people may have their own QA lead or manager.

Tool smith
The tool smith is responsible for developing build scripts, maintaining the source-code control system, developing specialized utilities needed by the project, and so on. Build coordinator. The build coordinator is responsible for maintaining and running the daily build (discussed in Chapter 14) and for notifying developers when their source code breaks the build.

Risk officer
The risk officer is assigned to watch for emerging risks,

End-user documentation specialists
These specialists are responsible for generating help files, printed documentation, and other instructional materials that end users will use.

TIME ACCOUNTING
The early part of a project is also a good time to begin detailed time accounting, that is, keeping track of how project personnel spend their time. Time accounting is a critical component of project visibility and control on the current project and lays the foundation for more accurate estimates and planning on future projects.

Tune-accounting data enables you to compare estimated time to actual time with the goal of improving future estimates. You can use the breakdown of time spent on activities from one project to help plan future projects. your project can use following the time-accounting categories to decide the time lines.

• Time-Accounting Category Activity
• Management
• Administration
• Process development
• Requirements development
• User-interface prototyping
• Architecture
• Plan
• Track progress/status
• Report progress/status
• Manage project team activities
• Manage customer/end-user relations
• Manage change
• Downtime
• Lab setup
• Create development process
• Review development process
• Rework development process
• Educate customer or team members about development process
• Create User Manual/Requirements
• Specification
• Review User Manual/Requirements
• Specification
• Rework User Manual/Requirements
• Specification
• Report defects detected during requirements development
• Create User Interface Prototype
• Review User Interface Prototype
• Rework User Interface Prototype
• Report defects detected during prototyping
• Create architecture
• Review architecture
• Rework architecture
• Report defects detected during architecture
• Preliminary Planning
• Time-Accounting Category Activity
• Detailed design
• Implementation
• Component acquisition
• Integration
• System testing
• Software release
• Metrics
• Create detailed design
• Review detailed design
• Rework detailed design
• Report defects detected during detailed design
• Create implementation
• Review implementation
• Rework implementation
• Report defects detected during implementation
• Investigate/acquire components
• Manage component acquisition
• Test/review acquired components
• Maintain acquired components
• Report defects in acquired components
• Automate build
• Maintain build
• Test build
• Distribute build
• Plan system testing
• Create manual for system testing
• Create automated system test
• Run manual system test
• Run automated system test
• Report defects detected during system test
• Prepare and support alpha, beta, or staged release
• Prepare and support final release
• Collect measurement data
• Analyze measurement data

Trust - Be Open and Honest
Be as open and honest with your team mates as you can. Answer their questions directly and act as a conduit of information for them, not a barrier. If you feel you cannot divulge something, say so. Your team will appreciate your honestly and reciprocate by relaying information and producing honest and accurate estimates for you.

Equality - Be fair and even handed
If there is a project issue that needs to be addressed you can normally broach it as a subject for the whole team to address. By sharing the burden for issues, most teams pull together to solve the problem. By landing it on the shoulders of one or more individuals you often split the team and cause conflict. Open discussion of the problem will encourage the team to take ownership for the problem and solve it themselves.
Loyalty - Protect your team
You will have a split responsibility - on the one hand you have a duty to your client to see the project succeeds - on the other you have a responsibility to represent your team and to support each other. Usually these two aims should be neatly aligned but not always! In a situation where you have to choose between the two you need to take the difficult moral stance. Discuss the situation with your team mates and come up with a solution, present this to the client instead.

Learn to delegate
If you are dividing up work make sure you delegate properly. Proper delegation entails laying out the task so someone understand its, so that it has reasonable and achievable goals and so that you give them all the support they require to get the job done. It also entails giving them enough room to get the task done on their own. If you leave the execution of tasks to them they will, in return, leave you alone to get on with your job. If you spend you time looking over their shoulders it will only annoy them and waste your valuable time.