140 likes | 250 Views
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 ,
E N D
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?