SRS Presentation

CEN4020: Software Engineering I

Software Requirements Specification Presentation

Instructions

The SRS presentation comes after your HCI presentation, but must be self-contained enough to be understandable without the HCI presentation. It differs from the HCI presentation in the following respects:

You are to focus on the other information that is in the SRS, that is not in the HCI prototype, such as the shall-lists and the various UML diagrams^*.
You are required to produce a set of self-contained PowerPoint slides for the entire presentation, and post them on your team's Trac website.
Although each team member must participate, you do not need to divide the time into equal 5-minute segments.
Each team member does not need to provide a separate self-introduction, and conclusion, or separate question-answer spots. You may start with one team-introduction, and may transition smoothly from one person to another, and may wait to the end of the entire group presentation to ask for questions.
One grade for the presention will go to the entire team, not separate grades to individuals.

^*Since this comes after the HCI presentation, you may have had time to incorporate into your SRS a few improvements based on user feedback from the HCI presentation. If you do, and if these impeovemens involve changes to the HCI prototype, you may explain those changes, but please do not turn this into a repeat of the HCI demonstration!

Each team will have a maximum of 25 minutes, inclusive of questions and answers, to make the SRS presentation.

You should again plan a storyboard for the presentation, but this time the story will not be about a user's interaction with the system, but will be a story about the product. It may help to think in terms of a logical progression of questions. For example, you might cover the following:

What are the context and business case for the project?
- What is the intended goal?
- Who are the expected users?
- How will they benefit from using this product?
- Who will pay for development?
- How will they benefit from this expense?
How do the project goal(s) translate into functional requirements?
Into non-functional requirements?
How will the product be used? (use case diagram fits in here)
What are the elements of the problem domain, and how are they related? (class diagram fits in here)

Do not do any of the following:

Refer to the SRS sections, or project sections of the SRS on the screen
Read from the SRS in your talk
Project images of UML diagrams that are too detailed to read from the back of the room
Try to cover everything in the SRS
Present the glossary
Present the data dictionary
Get bogged down in details

You should consider doing all or some of the following:

Convey the essence of what is in the SRS
Explain the goals for the product
Explain the proposed architecture
Abbreviate the statements of your functional and non-functional requirements on the slides
Walk through the requirements, with oral explanations that go beyond reading out loud the sentences of the SRS.
Walking through your use-case and class diagrams, explaining them
Split up the diagrams if they are too complicated to be readable if projected entirely on one screen
Define terms during your presentation that may need clarification, as they come up, in context.
Be prepared to use the data dictionary items during the Q & A session to answer any questions that may be raised.
Give a few illustrative details, where they help with understanding.

Some of the more important content from the SRS is:

Scope
Product functions (functional requirements)
General constraints (non-functional requirements)
User characteristics
Use case diagram
Class diagram

Remember to target the style and content of the presentation to your intended audience. The audience here is the customer. These presentations are your chance to market your understanding of the system and present unique ideas about the system to the customer. The customer wants to see that you clearly understood and conveyed his or her wants and needs for the proposed system.

Success of a presentation is a direct result of the amount of preparation, including review of the presentation materials and practice, by your team.

Grading Rubric for Presentation

ORGANIZATION (20 pts)		Strongly Disagree ... Strongly Agree
Name:
START TIME:	END TIME:	Grade
Introduction included name of presenter(s)		1	2	3	4	5
Introduction included purpose and brief overview		1	2	3	4	5
Concluded with definite ending and summarized main points		1	2	3	4	5
Presentation well prepared and well organized		1	2	3	4	5
CONTENT (40 points)
Essence of presentation clearly conveyed and understood		1	2	3	4	5
Enough, but not too much, material/detail given		1	2	3	4	5
Explanations appropriate and understandable		1	2	3	4	5
Knowledge and understanding of subject matter demonstrated		1	2	3	4	5
Questions handled well		1	2	3	4	5
DELIVERY (20 points)
Presentation appeared extemporaneous (spoken, not read or memorized)		1	2	3	4	5
Grammatical language used		1	2	3	4	5
Avoided vocal fillers ("You know", "Aahh", etc.)		1	2	3	4	5
Made good use of visual aids (overheads, chalkboard, computer demo, etc.) to support and enhance presentation		1	2	3	4	5
Visual aids easy to see, easy to understand		1	2	3	4	5
Presentation starts and ends on time		1	2	3	4	5
EFFECTIVENESS IN COVERING OBJECTIVES (20 points)
Presentation gave customer a clear understanding of what the product would do		1	2	3	4	5
Requirements were stated unambiguously		1	2	3	4	5
All high-level requirements were addressed		1	2	3	4	5
Interaction with and treatment of customer was appropriate		1	2	3	4	5
Customer feedback was sought and responded to		1	2	3	4	5
Area for notes:

$Id$