• Table of Contents

Requirements Elicitation

If you recall in Week 1, we briefly talked about the six main activities in software development.

Figure 3.1 Main activities in software development.

In COE691, we focused on the requirements elicitation — the definition of the system in terms understood by the customer.

• Functional requirements: Describe what the product does.
• Non-functional requirements: Describe how the product works — quality attributes.
• Constraints: Imposed by the client or the environment.

<aside> <img src="/icons/map-pin_gray.svg" alt="/icons/map-pin_gray.svg" width="40px" /> Refer to Software Requirements in 2 Basic and Fundamentals of Requirements Engineering for more info regarding this topic.

</aside>

Architects need to understand the functional requirements and create a platform that supports these and simultaneously satisfies the non-functional requirements and constraints.

Prototype

We can use a prototype to ensure all the requirements have been addressed, which we will implement in Lab 2. A prototype is just an incomplete version of how the real product will work and feel. It usually has the following steps:

1. Identify the basic requirements and finalize the middleware.
2. Create the initial prototype — a working user interface based on the middleware.
3. Customer examines the prototype and provides feedback on potential additions or changes.
4. Revise and enhance the prototype.

We can model functional requirements using a use-case diagram.

<aside> <img src="/icons/map-pin_gray.svg" alt="/icons/map-pin_gray.svg" width="40px" /> We previously covered use-case diagram which is in COE528. Refer to Modeling With UML I.

</aside>

Figure 3.2 Use-case diagram for a library management system.