J.E.D.I
Similar with developing the Use Case Model, one can refine and re-define the use case specification. It is also done iteratively. When to stop depends on the one modeling.
One can answer the questions presented in the Requirements Model Validation Checklist to determine when to stop refining and redefining the use case specifications.
3.3.3 Requirements Model Validation Checklist
Like any work product being produced at any phase, validation is required. Listed below are the questions that guides software engineers to validate the requirements model. It
is important to note at this time that the checklist serves as a guide. The software engineer may add or remove questions depending on the circumstances and needs of
software development project.
Use Case Model Validation Checklist
1. Can we understand the Use Case Model? 2. Can we form a clear idea of the systems over-all functionality?
3. Can we see the relationship among the functions that the system needs to perform? 4. Did we address all functional requirements?
5. Does the use case model contain inconsistent behavior? 6. Can the use case model be divided into use case packages? Are they divided
appropriately?
Actor Validation Checklist
1. Did we identify all actors? 2. Are all actors associated with at least one use case?
3. Does an actor specify a role? Should we merge or split actors? 4. Do the actors have intuitive and descriptive names?
5. Can both users and customers understand the names?
Use Case Validation Checklist
1. Are all use case associated with actors or other use cases? 2. Are use cases independent of one another?
3. Are there any use cases that exhibit similar behavior or flow of events 4. Are use cases given a unique, intuitive or explanatory names?
5. Do customers and users alike understand the names and descriptions of the use cases?
Software Engineering 80
J.E.D.I
Use Case Specification Validation Checklist
1. Can we clearly see who wishes to perform a use case? 2. Is the purpose of the use case also clear?
3. Is the use case description properly and clearly defined? Can we understand it? Does it encapsulate what the use case is supposed to do?
4. Is it clear when the flow of events starts? When it ends? 5. Is it clear how the flow of events starts? How it ends?
6. Can we clearly understand the actor interactions and exchanges of information? 7. Are there any complex use cases?
Glossary Validation Checklist
1. Is the term clear or concise? 2. Are the terms used within the use case specification?
3. Are the terms used consistently within the system? Are there any synonyms?
Software Engineering 81
J.E.D.I
3.4 Requirements Specifications
In the previous section, the requirements model was introduced and discussed. In this section, we will be focusing on the analysis model which provides a base model of what
the software functions, features and constraints are. It is the most important work product to be developed in the requirements engineering phase because it serves as a
basis for design and construction of the software. In this section, we will learn how the analysis model can be derived from the requirements model.
3.4.1 The Analysis Model
The Analysis Model is illustrated in Figure 3.8. It consists of two elements, particularly, Object Model and Behavioral Model.
To create the analysis model, the following input documents are needed. • Requirements Model
• Software Architecture Document Optional
Object-Model
It is created using the Class Diagram of UML. It is the most important diagram to be developed because it serves as the major input for the design engineering phase. It
consists of the Analysis classes which represent an early conceptual model for things in the system which have responsibilities and behavior. It is used to capture the first draft
Software Engineering 82
Figure 3.8 Analysis Model
Class Diagrams
Collaboration Diagrams Sequence Diagrams
