SynergySoft™ Distributed Meeting Scheduler Requirements Review Yasaman Haghpanah Ravindra Rudraraju Sowjanya Sakruti Jim Whitaker

Purpose To present our requirements team and our requirements gathering process, To present our vision statement, system goals, and an operational scenario, To present the current state of our requirements in their various types, and To present our plans for future work.

Participants – the “Team” Yasaman Haghpanah Our “System” world representative Ravindra Rudraraju Our “Developer” world representative Sowjanya Sakruti Our “User” world representative Jim Whitaker Our “Subject” world representative

Our Requirements Process Identified stakeholders and assumed roles; Subject, User, Developer, System “worlds” Used “initial requirements” as a starting point Performed “role playing” to identify, understand, and discuss the problem; Developed an “operational scenario” to aid in understanding and build consensus; Derived enterprise and software system, functional and non-functional, requirements; Traced system requirements through enterprise requirements to vision statement, goals, and operational scenario to verify requirements.

Vision Statement “The SynergySoft™ Distributed Meeting Scheduler will provide convenient means of scheduling (and rescheduling) physical and virtual meetings among members of the organization regardless of their physical locations in an efficient and cost-effective manner.”

System Goals Improved communication to meeting participants, Optimized selection of location (meeting room) given the list of meeting participants, Dynamic meeting “rescheduling” to offload the work required for rescheduling a meeting, Support for “virtual” meetings Support for user authentication and authorization of features, and Optimized implementation in terms of computational and network resources, human involvement and interaction, and rapid response times.

Operational Scenario Recast the “initial” requirements document to an “operational scenario” to eliminate conflicts, reduce confusion, and to reorganize the requirements into a more useful form; Used the “operational scenario” to begin developing a consensus among the stakeholders and to precipitate issues for discussion and resolution; Operational scenario improved our understanding of the key requirements (use cases) and interactions (sequence diagram);

Enterprise Requirements Asks Domain level questions Who are the stakeholders? How does one schedule a meeting? What are the issues with scheduling meetings? How are these issues resolved? Domain Requirements Modeled Using UML Use Case diagrams depict functional requirements System Sequence diagrams depict interactions

Examples of Enterprise Requirements Enterprise Functional Requirements A “meeting initiator” shall initiate a meeting by deciding on a “meeting topic”, by selecting a list of “potential meeting participants”, and by selecting a “date range”, “duration”, and “location” for the meeting. Enterprise Non-Functional Requirements Any physical changes to the “location” and its “required equipment” shall be kept up-to-date.

System Requirements Functional Requirements Define the behavior of the system; Non-Functional Requirements Define the constraints under which the system must operate

Examples of System Requirements Functional Requirements “The system shall calculate the optimal meeting location using the office locations of each confirmed meeting participant based on distance.” Non-Functional Requirements “The system shall be user-friendly and provide a convenient, intuitive interface.”

Requirements Traceability Provides the ability to track any requirement “forward” (to a lower level of specification) or “backward” (to a higher level of specification) Insures that requirements are not omitted or created by “whim”

Next Steps Semi-formal Specification Process Specification Implementation Testing

Thank you… Questions?