Explain The Requirements Discovery Process

Explain The Requirements Discovery Process

Requirements discovery is the process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information. Sources of information during the requirements discovery phase include documentation, system stakeholders, and specifications of similar systems. You interact with stakeholders through interviews and observation and may use scenarios and prototypes to help with the requirements discovery.

In this section, I discuss an approach that helps ensure you get broad stakeholder coverage when discovering requirements, and I describe techniques of requirements discovery including interviewing, scenarios and ethnography. Other requirements discovery techniques that may be used include structured analysis methods.

Stakeholders range from system end-users through managers and external stakeholders such as regulators who certify the acceptability of the system. For example, system stakeholders for a bank ATM include:

1. Current bank customers who receive services from the system.

2. Representatives from other banks who have reciprocal agreements that allow each other's Arms to be used.

3. Managers of bank branches who obtain management information from the system.

4. Counter staff at bank branches who are involved in the day-to-day running of the system.

5.  Database administrators who are responsible for integrating the system with the bank's customer database.

6. Bank security managers must ensure that the system will not pose a security hazard.

7. The bank's marketing department who are likely interested in using the system as a means of marketing the bank.

8. Hardware and software maintenance engineers who are responsible for maintaining and upgrading the hardware and software.

9. National banking regulators are responsible for ensuring that the system conforms to banking regulations.

In addition to system stakeholders, we have already seen that requirements may come from the application domain and from other systems that interact with the system being specified. All of these must be considered during the requirements elicitation process.

These requirements sources (stakeholders, domain, systems) can all be represented as system viewpoints, where each viewpoint presents a subset of the requirements for the system. Each viewpoint provides a fresh perspective on the system, but these perspectives are not completely independent-they usually overlap so that they have common requirements.