Understand the Requirements and Design Constraints

As a developer, it is essential that you understand the requirements. The first step is to read through the Vision, which gives a high-level understanding of what the system should do, providing you with the bigger context of how your piece of the project fits in the overall solution.

Functional requirements are primarily documented in use cases. You may be responsible for implementing the capabilities of anything from a partial use case to several use cases. To get acquainted with a use case, read through the use-case description. You find an example of the use-case description in the section Detail Actors and Use Cases, in Chapter 15. It is also essential that you review or take part in the development of the user-interface prototype. It will provide you with a better understanding of what capabilities the users expect from the use case. You can find more information about the user -interface prototype in the section Develop User-Interface Prototypes, in Chapter 15. Especially for smaller projects, you may have the same person doing analysis and design of a use case. This automatically provides the developer with an in-depth understanding of the use case, since he or she participated in describing it.

Nonfunctional requirements are documented in the Supplementary Specification, in the RUP, which contains requirements on performance, usability, platform support, and technical and other constraints. For example, you may not use any open -source software in your application. It is important that you read through this document, so you can choose the right technical solution within the constraints in which your implementation must reside. Note that for smaller projects with less ceremony, these nonfunctional requirements may not all be documented. If this is the case, you need to communicate with analysts and other stakeholders to ensure you have a good understanding of the nonfunctional requirements.

As a developer, you are responsible for architectural control of the part of the system that you design. This means that you need to work hand-in-hand with the architect to ensure that your design fits within the overall architecture. Information about which architectural mechanisms (common solutions to common problems) are supposed to be used is found in the Software Architecture Document. Here you may find ready-made solutions for how to handle communication with external systems, deal with persistency, handle garbage collection, and so on. The SAD also contains information about the major building blocks and their interfaces ”information that will help you understand the architecture within which your code will coexist. For smaller projects with less ceremony, architectural decisions and architectural mechanisms may not all be documented in the SAD. In this case, you need to work closely with the architect, making sure that you fully understand the architecture.

As you design, implement, and test your solution, it is essential that you communicate and demonstrate progress to the extended team, including representatives of the user. By demonstrating partial solutions, you can get early feedback, allowing you to make necessary improvements to your implementations when it is easiest to do so.

As you design, implement, and test the application, you are likely to notice inconsistencies or "holes" in the requirements. It is important that you provide the analyst with this information, so the analyst can correct or refine the use cases.