Requirements Review

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
– 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
• 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
– 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
– Every mission objective should relate to some user
– 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
– Reminders and password forget
Transaction and Transactional
• 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
– 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.
• 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.