REM in Agile Projects - Requirements Engineering and Management for Software Development Projects - page 221

project team. Some of them go to the extent of mandating that the customer/
representative/user must be part of the project team
3. They all believe in developing the code
4. They try and minimize the documentation
5. They all focus on delivering the code, that is the software engineering part
6. They all do not talk about the ''management part'' of the software development
project.
All in all, strictly speaking agile methods are software engineering methodol-
ogies rather than management methodologies. Second, they all focus on designing,
building and testing the product and more or less silent on the aspects of
requirements engineering and management. They also do not acknowledge the
need to trace the requirement through all the engineering artifacts.
The philosophy of agile methodologies seems to be that the customer is
responsible to take care of the requirements and ensure that they are implemented.
By co-locating the customer or making the customer part of the project team they
ensure that the requirements are efficiently taken care of. As, many projects are
handled using the agile methods, we have to acknowledge that the philosophy is
indeed working.
Still, agile projects do establish the requirements in some way even though the
rigor of such establishment may not match with the rigor of the other software
development methodologies. Here are some ways in which requirements are
established in agile projects:
1. User Story cards—users write user stories on cards. Each card would contain
one feature for a program. One card may result in one program or multiple
cards may be necessary to complete a program. The card may not give full
information to the programmer. More often than not, a conversation between
the programmer and the user would be necessary for the programmer to fully
comprehend the requirement and program it.
2. Task list—Task list is another means to document the requirements. It is an
enumeration of the requirements or user stories that need to be developed. This
list gets updated as and when the tasks are completed to indicate the project
progress.
3. CRC cards (Class, Responsibility and Collaboration)—Each card records the
requirements and the interaction between requirements in such a way that
software can be designed and constructed.
4. Customer acceptance test cases—List of user acceptance test cases also serve
as project requirements.
5. Feature lists—List of features to be built into the product is another mecha-
nism to establish project requirements. Each feature must possess some client
value and should be implementable in 2 weeks or less.
6. Informal Use Cases—Agile projects use scaled down use cases with much
reduced rigor in describing the scenarios of the use cases
7. Product backlog—This is another mechanism to record the requirements. In
this the features yet to be completed are enumerated. These are described not as