COMP 208214215216 Lecture 4 Requirements Walkthrough Requirements Review

COMP 208/214/215/216 Lecture 4 Requirements Walk-through

Requirements Review Meeting • This meeting reviews the outputs of the first three steps of the method in Connolly and Begg. • It will review the 7 items of documentation which should be produced in this phase of the project • This review counts as 15% of your group mark.

Organisation Details • The Requirement Specification Walkthroughs will take place in week 4 (between 20– 24 February 2012) • Teams are responsible for arranging a time for the review – Send e-mail to me, cc-ed to all group members – Make your booking by Friday 17 February. • The documentation to be reviewed must be submitted to the school office on or before 12 noon Friday 17 February • Reviews will typically last 20 -30 minutes, well organised submission clearly written and fully complete will have an easier time at review

Documentation Required • • Mission statement Mission objectives System Boundary Diagram User Views and Their Requirements Transaction Requirements (if appropriate) Systems Specification Project Gantt Chart. Descriptions and examples of items 1 -6 are in Connolly and Begg Chapters 3 and 4 (1 st edition) or Chapter 6 (2 nd edition).

Format of the Review • For each deliverable: – A team member introduces the item – The reviewer may ask questions for clarification • Team replies to questions – The reviewer may make comments • Team may briefly respond to comments • A Report Form will be completed by the reviewer and given to the team as soon as possible.

Mission Statement • The mission statement is a single sentence which defines the overall purpose of the database: what it is for • It should be clear and unambiguous • It is not a list of functions that the database will perform: it is the reasons why those functions are wanted. Stay. Home example: p 64 of Connolly and Begg (p 129 in 2 nd edition).

Mission Objectives • The Mission Objectives statement is a list of particular tasks that the system will support • Each objective begins with an infinitive – To maintain/ perform/ track/ find/ report/ show/ record etc. – Indicates which data items to be used • Tasks supported - not who will do them • Should be as comprehensive as possible. Example: Figure 4. 8 of Connolly and Begg (Figure 6. 8 in 2 nd edition).

Systems Boundary Diagram • The intention of this diagram is to represent the main types of data relevant to the system • The boundary shows what will be included in the system and what will be not. Data may be: – In the system – Available on other systems to which links will be provided – Not to be available at all. Figure 4. 9 of Connolly and Begg provides an example (Figure 6. 9 in 2 nd edition).

User Views and Requirements • Purpose: to identify the major classes of user and the functions they will use. – e. g. administrator, teacher, pupil: • Administrator maintains the database: views, adds, modifies, deletes records • Teacher customises the database: views and adds records, but doesn’t modify or delete records • Pupil uses the database: only views records. • In other applications, different users may maintain and use different data items.

More on User Views • We are producing a list of users and, for each user, the functions they need: • Functions should relate to mission objectives: – Every user function should be included in mission objectives – Every mission objective should relate to some user function – Several users may use the same function. Example at figure 4. 10 of Connolly and Begg (Figure 6. 10 in 2 nd edition).

Other roles • Developer account – Same as standard user but… – Allows for special test cases – E. g. credit card 12341234 – (not LUHN tested) • System admin (different from admin) – Technical admin account – Allows backup and re-configuration

Other issues • Logging – All transactions (cash or otherwise should be logged, i. e. stored in database table) – E. g. • log id, Userid , amount, description, payment id • 100, 1045, 100, ”Purchase of book”, 12 • Error logging – Store in error log on database all bug logs • Audit/security logging – Store in log, if when user gets password wrong, or wrong 3 times (you decide)

System monitoring • How do you keep your system up • Checkout … Pingdom • What will you do if your payment server goes down…? – Backup services and fail over

Connecting to external services • Payments – CC card – Paypal – Google • Email – Password forget • SMS – Reminders and password forget

Transaction and Transactional Requirements • Each user view will involve certain transactions, stipulating how the data is to be used • There are three broad categories: – Data entry: every data item needs to be created somewhere – Data update and deletion – Data queries • Transactions should be related to the user view to ensure all functions are supported • Do transactions needed to be atomic

System Requirements • Various aspects to cover here: – Initial Database Size – Rate of Growth – Expected type and frequency of searches – Network and Access requirements – Performance – Security – Back-up and Recovery – Legal Issues • Detail required will vary according to application and environment – e. g. a stand alone single user application will need less detail on access and requirements than a commercial multi-user system.

Project Gantt Chart • A chart showing the major milestones, tasks and deliverables of the project and when they are scheduled • You need to report your past progress and future plans. • You will need to update this chart for each Walkthrough.

Summary By FRIDAY 17 FEBRUARY 2012 • You must book your meeting. • You must supply the requirement documents During the week 20/02/12 - 24/02/12 • You must attend the review meeting • Please attend the meeting punctually • This review is an important milestone: it lays the foundations for the project.