COMP208/214/215/216. Lecture 4. Requirements Walk-through

Transcription

1 Groups All Set

2 COMP208/214/215/ Lecture 4 Requirements Walk-through

3 Announcements All teams are set up Each team has a MONITOR (information available on VITAL, make sure you know who (s)he is) Each team will be allocated a (possibly different) REVIEWER for each assessment milestone.

4 REQUIREMENT REVIEW

5 PLEASE READ CAREFULLY PAGES OF

6 Requirements Review Meeting This meeting reviews the output of the requirement analysis process. Its main purpose is to ensure that an appropriate and feasible system is planned for implementation by each team, and that the team is working following a reasonably well-defined plan. This review accounts for 12% of your mark. No turn up? You only get marks for report. Late submission is possible but only for report

7 Organisational Details The Requirement Specification Walkthroughs will take place in week 4 (between February 2018) Teams are responsible for arranging a time for the review with their reviewer by Friday 16 February. The documentation to be reviewed must be submitted on VITAL on or before 12 noon Friday 16 February. Reviews will typically last around 30 minutes.

8 Assignment

9 Documentation Required Project description Mission statement Mission objectives Statement of Deliverables, include as appropriate System Boundary Diagram User Views and Their Requirements Transaction Requirements Systems Specification Conduct of the Project and Plan (including a project Gantt Chart if appropriate). Bibliography

10 FURTHER READINGS Descriptions and examples for some of the items are in Connolly and Begg Chapters 3 and 4 (1 st edition) or Chapter 6 (2 nd edition). Sebastian Coope s Software Engineering notes (in particular Lecture 4, 5 and 6) are a valuable resource.

11 Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture 4 6 Software Requirements COMP201 - Software Engineering 11

12 Topics Covered Functional and non-functional requirements User requirements System requirements The software requirements document COMP201 - Software Engineering 12

13 Software Requirements Descriptions and specifications of a system Last time: Introduce the concepts of user and system requirements Described functional / non-functional requirements This lecture: To explain two techniques for describing system requirements To explain how software requirements may be organised in a requirements document COMP201 - Software Engineering 13

14 Objectives To describe the principal requirements engineering activities and their relationships To introduce techniques for requirements elicitation and analysis To describe requirements validation and the role of requirements reviews To discuss the role of requirements management in support of other requirements engineering processes COMP201 - Software Engineering 14

15 USEFUL EXERCISE cross check these slides with Seb s (e.g. System Boundary/UCDs) What is relevant / irrelevant? Try to come up with your own process Don t overdo it! If something is NOT needed, DON T use it!

16 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.

17 DOCUMENTATION

18 DISCLAIMER 1. Content of forthcoming slides ADVICE ONLY, 2. Most examples refer to a standard DB system 3. Significant deviations will be penalized, BUT 4. Adjustments may be needed because of specific aspects of each project USE YOUR JUDGEMENT!

19 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 system will perform: it is the reasons why those functions are wanted. StayHome example: p 64 of Connolly and Begg (p129 in 2 nd edition).

20 Mission Objectives The Mission Objectives statement is a list of particular tasks that the system will support Should be specified using domain specific language and terminology 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).

21 Systems Boundary Diagram The intention of this diagram is to represent the main types of data relevant to the system and their relationships 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).

22 Example of System Boundary Template Administrator System Boundary Mobile User WAP User Interface Database

23 Use Case Diagrams COMP201 - Software Engineering 23

24 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.

25 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.

26 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).

27 Transaction 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.

28 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.

29 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.

30 Summary By FRIDAY 16 FEBRUARY 2018 You must book your meeting. You must supply the requirement documents During the week 19/02 23/02 You must attend the review meeting Please attend the meeting punctually This review is an important milestone: it lays the foundations for the project.