1. 1 CMPT 275 Software Engineering Requirements Analysis Phase Overview of Requirements Analysis Activity System Context Diagrams

2. Janice Regan, 2008 2 Requirements Gathering/Specification Client/User Software Developer Project Description Informal Scenarios Questions Requirements Specification Document 12 3 4 5 6 73 7 8 84 4 Client meeting 8 Client requirements review meeting

3. Janice Regan, 2008 3 Project: Requirements Analysis  Requirements gathering and specification will allow you to build an ‘analysis model’. This model represents the user’s/client’s view of the system  You will end up with a list of functional requirements.  Each requirement will represent one function/activity  This is your ‘analysis model’  Functional requirements are not dependent on specific methods of implementation

4. Janice Regan, 2008 4 Project: Requirements Analysis  Y our list of functional requirements will  Describe the required interactions between the system and its environment (independent of implementation)  You will also need a list of non-functional requirements  QUALITY REQUIREMENTS: Usability, reliability, performance, maintainability  CONSTRAINTS or PSEUDO REQUIREMENTS: Implementation (tools, languages), interface (to external systems), operation (admin, management), packaging, Legal

5. Janice Regan, 2008 5 Project: Requirements Analysis  You requirements must be  Complete: all required features must be described  Consistent: no two requirements in the specification may contradict each other  Unambiguous: no requirement can be interpreted in two different and contradictory ways  Correct: Only features desired by the client / developer are included not unintended extra features (problems)

6. Janice Regan, 2008 6 Class Project: Requirements Analysis  Next you will proceed using use case centered development (UCCD) to your requirements model  System Context Diagram  Identifying Actors and developing Use Cases  Primary classes  Use cases and Scenarios (formal and informal)  Use case Diagram  Class (object) Diagram  State Diagrams

7. Janice Regan, 2008 7 Requirements Analysis Activity Software Developer Client/User Update SRS Questions Use Case Centered Development (UCCD) System Context Diagram Use Cases Primary Classes Use Case Diagram State Diagram Class Diagram Scenarios

8. Janice Regan, 2008 8 Roles  Participants are people associated with the project (software system)  Client, developer, manager, end user  A set of related tasks that are assigned to a participant is a role  A student (role) is assigned a group of related tasks: registers in classes, receives grades  A teacher (role) is assigned a group of related tasks: gives classes, marks student work, gives grades

9. Janice Regan, 2008 9 Actor  Entity outside the software system  interacts with the system  Operates on objects in the system but cannot be operated upon by objects in the system.  Human, hardware device, another software system  Represents coherent role played by users  e.g.: In an automated registration system teacher, student, registrations data base

10. Janice Regan, 2008 10 Actor  A user of software system may take on more than 1 role, usually at different times  e.g.: Eva interacts with the system not only as a student actor but also as a teacher actor  Eva teaches math, but is a student of French  An actor may represent more than one user  e.g.: Both Eva and John may take the role of a student

11. Janice Regan, 2008 11 Primary and Secondary Actors  Primary Actors  Actors who initiate a scenario (use case) causing the system to achieve a goal  automated registration system example the student or teacher is a primary actor  Secondary Actors  Actors supporting the system so primary users goals can be completed (do not initiate the use case or scenario)  automated registration system example the registration data base is a secondary actor

12. Janice Regan, 2008 12 Primary and Secondary Actors  It is possible for an Actor to be a primary (initiating) actor in one scenario and a (non-initiating) or secondary actor in another scenario in the same system  For example in the automated registration system example  When Eva registers in a French class she is the primary actor (student) and the registration data base is the secondary actor.  Periodically the registration data base (primary actor) uses the registration data base to print notifications of registration to be sent to students.

13. Janice Regan, 2008 13 System Context Diagram: LMS Librarian Patron Resources (Books, CDs..) Software System Being created Web Libraries Student Information Repository (DB) Employee Information Repository (DB) Online Journals Show how the software system interacts with its environment Resource Information Repository (DB)

14. Janice Regan, 2008 14 System Context Diagram: LMS Librarian Patron Resources (Books, CDs..) Software System Being created Web Online Journals Show how the software system interacts with its environment DB components are custom components developed specifically for this application and are thus part of this application