COMP208/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 (1st edition) or
Chapter 6 (2nd 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.
StayHome example: p 64 of Connolly and Begg
(p129 in 2nd 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
2nd 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 2nd 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 2nd edition).
Other roles
• Developer account
– Same as standard user but…
– Allows for special test cases
– E.g. credit card 1234123412341234
– (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.