3RA3 Assignment #2 Solutions – 2017

Please note that these solutions are only one possible version, as many specifics in the requirements analysis are often subjective. Each individual may come up with slightly different solutions. This can be one of the issues on a project if there is insufficient coordination between teams. Question 1 (20=8+8+4)

IEEE830 Requirements Document

Section 1

A newly formed company wishes to develop a system capable of searching for flights, and then

allowing booking of seats on those flights.

The following subsections of the SRS document should provide an overview.

1.1 Purpose

This document is written to specify as many requirements as possible for the WFB System.

The intended audience includes all stakeholders, including ownership, and supervising management.

This document also clearly defines requirements for the designers, engineers, and builders of the

system.

1.2 Scope

a) The WFB system will make use of a data retrieval engine.

b) The DRE will be used to access data of users of the system to prepare their tickets.

1.3 Definitions, acronyms, and abbreviations

SRS – Software Requirements Document

Member – A user with an account with the WFB Airline booking system

Non-member – A user without an account with the WFB system

Flight Number – A unique number associated with each flight. Each flight number has an associated

departing and arriving city.

WFB – Wonderland Flight Booking

DRE – Data Retrieval Engine

1.4 References

The IEEE830-template was referenced from the 3RA3 website.

http://www.cas.mcmaster.ca/~se3ra3/misc/RequirementsSpecificationInIEEE830.pdf

Any other documents that are referenced in the SRS should be here also.

1.5 Overview

This SRS begins with an overall description of the problem, and the reason for the project taking place.

Section 2 – Overall description

Section 3 – Requirements

Section 4 – Supporting information

Section 2 – Overall description

2.1 Product perspective

This system will access the flight data recorded by airplanes.

This system will make use of a Data Retrieval Engine.

2.1.1 System Interfaces

The system shall include the following interfaces depending on the situation:

1.1 – registration page (2 versions with/without social media)

1.2 – logged in flight search (with logout/account pane)

1.3 – logged out flight search (with register pane, link account pane)

1.4 – flight purchase page

1.5 – seat selection/placement page

2.1.2 User Interfaces

The requirements may be satisfied with any screen format, page or window layout, or any of a variety

of ways as long as the components listed in 2.1.1 are present.

All error messages should be checked for clarity to ensure they convey the correct information to the

user.

2.1.3 Hardware Interfaces

Both Windows, and Mac will be supported.

Hardware that may be used to interact with the system includes: screen, finger, stylus,

An app version of the system will be supported for the Apple App store, and Google Play store.

2.1.4 Software Interfaces

The WFB system must interface with the DRE which will provide it the users social information.

2.1.5 Communications Interfaces

Local network protocols, and protocols to interact with flight data will be developed from scratch, thus

no specific requirements are known until after interviews with stakeholders.

2.1.6 Memory Constraints

The database shall be able to hold at least 100 Petabytes of information including user data, flight

information, scheduling, etc.

2.1.7 Operations

The system shall associate a different mode of operation to each of the interfaces in 2.1.1.

The database of flight and user information shall be backed up routinely with no more than 5 minutes

between backup copies being bade.

2.1.8 Site Adaptation Requirements

No site specific requirements as users may interact with the system from anywhere they choose.

2.2 Product functions

The system shall perform the following major functions:

-accept registrations

-perform flight searches based on departure and/or arrival cities

-allow the purchase of seats on a flight

-allow the selection of seats

-provide confirmation of purchase

2.3 User characteristics

The WFB system will be easily accessible by anyone regardless of education or technical expertise.

Even children should be able to navigate the flight search functionality, though users must be over 18 to

register and book flights.

2.4 Constraints

Regulatory policies for the locations the system will operate in must be researched, and added here.

Information shall be stored in formats which are compatible with the DRE output from each member.

Other constraints are unknown at this time, and will be determined through interviews with

stakeholders.

2.5 Assumptions and dependencies

The WFB System assumes that:

Users will be a valid internet connection.

Users will be able to interact with common ubiquitous file formats such as .pdf, and .doc.

2.6 Apportioning of requirements

Satisfaction of search requirements may not be necessary for initial testing.

The ability to select and purchase specific seats on a plane will not be required for initial deployment.

Section 3 Specific Requirements

3.1 External Interfaces

Any member may provide the system with flight origin and destination cities, and be returned with a

list of available flights.

If they wish to purchase tickets, users will be giving the system their registration information including

name, address, email address, and password, as well as possible social account information through the

Data Recovery Engine.

The system is responsible for generating a unique frequent flyer number for each new member user.

3.2 Functions

The proposed system shall: -* Require member users to log in to their account prior to booking a flight - * Allow members to search for available flights, to reserve a seat, to book a flight, cancel a flight, and to edit

their member information - allow non-member users to only search for available flights - * Require non-member users to create an account in order to reserve a seat or to book a flight -allow members to login using frequent flyer number as a username and require a sufficiently safe password -give users the option of linking their Google or Facebook accounts to their frequent flyer number, to simplify

login -check both the frequent flight number and password, when a user attempts to login -allow non-member users to enroll and to create a new account with the website -require the user to provide required information such as first name, last name, email address and password to

create a new account -allow only a password and signin to linked social media account -accept other optional information, such as phone number, credit card information and mailing address, during

the registration process -check if all required data are provided and then will prompt the user to enter additional information, if required -

auto-generate a unique frequent flyer number for the user after all required information is provided -allow the user to use this frequent flyer number as username for future authentications -accept data from a DRE implementing social media site’s APIs to retrieve user’s app data -provide users with the option of logging in with a variety of accounts -allow a logged-in user to purchase seats for an airplane flight -present the user with information on all (currently available) flights -allow the user to then select a pair (departure and return) of flights on which to purchase seats -allow the user to then indicate the number of seats and placement -guide the user completely through the checkout process -allow any customer to reserve a seat (closer to the front, window seat, aisle seat, etc.) once they have purchased

a ticket -indicate the seats to be reserved, initially found through the user’s previous bookings -display available seats for the departing and returning flights booked by the user -allow the user to select seats from each flight, where the number of selected seats from each flight is the number

that the user booked on that particular flight -allow the user to confirm the seat selection after selections are made -remove confirmed seat selections from available/unreserved seats and link the user’s booking to those particular

seats -assign the user randomly a seat from available seats 30 minutes prior to initial takeoff time if the user fails to

reserve a seat prior to flight takeoff -reduce the number of remaining seats by the number of tickets purchased as soon as purchase is confirmed -allow the user to return and use the function to book seats any time after up until 30 minutes prior their flight -provide the user a choice of available flights from which to pick -allow a user to query flight schedules based on simple input criteria -display the following information: Flight Number, Departing City and Date/Time, Arriving City and Date/Time,

Number of Available Seats when the user provides departure and arrival cities, and a departure/return date. -define a “matching” flight as one that uses the departure/arrival cities at a flight time greater or equal to the time

provided by the user -alert the user that no matching flights can be found, if none are found

-allow customers to query the system to find flight information, even if they are not at an airport (e.g., on their

mobile phone) -allow the user – whether a member or not – to view flight information that matches input criteria. The user will

provide: 1-A Flight Number and Date; or 2-Departing/Arriving Cities and Date. -display matching flight information including: Flight Number, Departure City, Arrival City, and Status as one of

the following: In Flight, At the Gate, Delayed, or On Time. -display the number of remaining seats, if available -allow the user to modify their account information, including the power to view, edit, save, or delete the

information stored in the logged in account -allow a user to change or cancel a flight that is already booked and change his/her address, phone number, email

or password -provide a way for the user to securely log out of the system -save all user operations when he/she exits the system -record the state of the user’s last search -retrieve the last state on the next login, and restore it -require a user wishing to continue accessing the website to log-in again to access user features

3.3 Performance Requirements

i) *The application shall generate a new frequent flyer number in less than 5 seconds.

ii) Other than search (which can take long), the application shall respond to a user request in less than 10

seconds.

iii) The application shall occupy less than 20MB when installed, shall not dry the device battery, etc.

iv) The application shall handle a load of 2,000 concurrent users.

3.4 Logical Database Requirements

The database shall operate on encrypted data.

It shall only be accessible locally, by our system once requested by a member user.

Only a selected few will have access to the maintenance of the database.

(To ensure that should there be a loss of information, there is a small pool of people who could have

leaked)

User data shall be backed up at a physically distributed site in case of system crash.

User data shall be kept for 5 years after a member closes their account.

3.5 Design Constraints

3.5.1 Standards compliance

The system shall use data formats which are compatible with flight software.

The system shall include algorithms to allow expedited audit tracing.

3.6 Software system attributes

3.6.1 Reliability

The WFB System should return the least expensive flight 99.95% of the time.

If the system is for some reason unsure which flight satisfies this criteria, it will return an error rather

than possibly providing inaccurate information.

3.6.2 Availability

The system shall be available for flight searches at almost all times. Only one scheduled downtime for

one hour each month will be required for certain offline maintenance.

3.6.3 Security

i) * All user data shall be kept confidential ii) Once the user is logged in, all communication shall be made through secure (encrypted) channels iii) The administrative control panel for the online booking system shall be accessed only by authorized

personnel. iv) Logged in users shall be able to access only their own data. v) User data shall be backed up at a physically distributed site in case of system crash.

3.6.4 Maintainability

i) The software application is to be easily modifiable in the case the client needs further features.

ii) The application should notify users’ devices when they must update the application.

iii) The application shall be ready to be deployed on other OS.

3.6.5 Portability

i) *The application shall be available for Android, IOS, and Blackberry devices. ii) *The application shall be available for both MacOS and Windows on desktops. iii) The application shall be translated in various languages.

3.7 Organizing the specific requirements

3.7.1 System Mode

There shall be two designated modes. The first shall be for normal operations only, and a second shall

be for testing, debugging, and emergencies.

3.7.2 User Class

There shall be two classes of users. Each user will be designated as either a member or non-member

according to whether they have a registered account.

3.7.3 Objects

Flights are real-world counterparts to objects in the system.

Flights have required attributes of Departure and Arrival time, Departure and Arrival Cities, airline, and

a list of seats. Associated with each seat can be up to 1 passenger.

3.7.4 Feature

Features include: accept registrations and returning a frequent flyer number, perform searches for

flights based on departure and/or arrival cities, facilitate the purchase and selection of seats and

returning a confirmation that the seats have been purchased.

3.7.5 Stimulus

The only stimuli will be input from the user, as described in the previous section (3.7.4)

3.7.6 Response

The system shall respond to registration requests, flight searches, seat purchasing, seat selection, log-

ins, log-outs

3.7.7 Functional hierarchy

Registration will consist of one of the following two groups:

Group A

-inputting first name

-inputting last name

-inputting password

-inputting confirm password

-inputting possible frequent flyer number

Group B

-inputting information, and granting access to social media account data

-inputting a password

-inputting a possible frequent flyer number

3.8 Additional comments

No additional comments at this time. Section remains here for comments during the revision process.

Section 4 – Supporting Information

4.1 Table of Contents

Section 1 – Introduction Page

1. Overview………..……..……………………………..………………………………………...1

1.1 Purpose……..…..……………………………………………………………………………..1

1.2 Scope……….…..……………………………………………………………………………..1

1.3 Definitions, acronyms, and abbreviations…………………………………………………….1

1.4 References..…………………………..……………………………………………………….1

1.5 Overview……………………………………………………………………………………...1

Section 2 – Overall description

2.1 Product perspective…..……………………………………………………………………….2

2.1.1 System Interfaces…………………………………………………………………………...2

2.1.2 User Interfaces……..……………………………………………………………………….2

2.1.3 Hardware Interfaces………..……………………………………………………………….2

2.1.4 Software Interfaces…………..…………………………..……………………………...….2

2.1.5 Communications Interfaces……………………………..………………………………….2

2.1.6 Memory Constraints…..…………..………………………………………………………..2

2.1.7 Operations…..…..…………..……….………………………………..…………………….2

2.1.8 Site Adaptation Requirements……………………………………………………………...3

2.2 Product functions..…………..……..…………………………………………………………3

2.3 User characteristics…………………………………………………………………………...3

2.4 Constraints…..…..…..………………………………………………………………………..3

2.5 Assumptions and dependencies………………………………………………………………3

2.6 Apportioning of requirements…..…..……………..…..……………………………………...3

Section 3 Specific Requirements

3.1 External Interfaces………………………..…………………………………………………..3

3.2 Functions……………………………………………………………………………………..4

3.3 Performance Requirements…………………………………………………………………..5

3.4 Logical Database Requirements………..…….………………………………………………5

3.5 Design Constraints…..…..……………………………………………………………………5

3.5.1 Standards compliance………………………………………………………………………5

3.6 Software system attributes………………..…..………………………..……………………..5

3.6.1 Reliability…………………………………………………………………………………...5

3.6.2 Availability………………………………………………………………………………….6

3.6.3 Security…………………………..…………………………………………………………6

3.6.4 Maintainability……………………………………………………………………………..6

3.6.5 Portability…………………………………………………………………………………..6

3.7 Organizing the specific requirements…..…..…..…………………………………………….6

3.7.1 System Mode…..…..……………………………………………………………………….6

3.7.2 User Class…………………………………………………………………………………..6

3.7.3 Objects……………………………………………………………………………………...6

3.7.4 Feature……………………………………………………………………………………...6

3.7.5 Stimulus…………………………………………………………………………………….7

3.7.6 Response……………………………………………………………………………………7

3.7.7 Functional hierarchy..……………………………………………………………………….7

3.8 Additional comments…..…………………………..………………………………………….7

Section 4 – Supporting Information

4.1 Table of contents and index…..…..………………………………………………………..….8

Volere Template

1. The purpose of the Project

1a. The User Business or Background of the Project Effort

The project is being initiated by the newly formed WFB company, for the purpose of serving customers

flight search & booking needs.

1b. Goals of the Project

We want to give quick and accurate search results to customer flight queries, and allow customers to

purchase flights they discover.

2. The Client, the Customer, and Other Stakeholders

2a. The Client

Wonderland Flight Booking company – for all intents and purposes the board of directors can be

considered the ultimate client, but discussions for most requirements will be made through operational

management.

2b. The Customer

Prospective airline users/customers – will want to be able to use system efficiently. They want a user

friendly interface, which is cost effective (keep overhead low).

2c. Other Stakeholders

Technical team – determine the system running environment, technical problems and responsible for

integrating social media

Ad Vendors – Will want to be able to sell travel related merchandise.

Prospective WFB Employees – Will want to be able to carry out customer requests quickly until the last

possible time at the airline service counter.

3. Users of the Product

3a. The Hands-On Users of the Product

This system shall be accessible by any user since searching is supported for non-members.

Member users shall be considered adults over the age of majority, who have confirmed their identity

through either a credit card or social media profile.

3b. Priorities Assigned to Users

The highest priority is to satisfy paying customers, but since non-members may access the system, it

must be simple to use, and return relevant results to all users so that non-members might be motivated

to purchase seats with us.

3c. User Participation

The system shall be designed for the public to use easily and seamlessly, so once a prototype can be

generated (to work offline with test data) user studies will seek to refine the design.

3d. Maintenance Users and Service Technicians

4. Mandated Constraints

4a. Solution Constraints

The search operation should be designed in a robust way, so that it reliably returns accurate flight

information, and sorts the flights by cost.

4b. Implementation Environment of the Current System

-There is no current system. The system being designed is for a new company.

4c. Partner or Collaborative Applications

-The system will have to interact with both a flight database, and a booking database. -

Interviews may be required to derive constraints.

4d. Off-the-Shelf Software

-Attempting to emulate similar applications could greatly reduce the time needed to

design and implement the app.

-Using off-the-shelf application for payment

4e. Anticipated Workplace Environment

-Users will access the system from anywhere with an internet connection, at any time.

-No influences on the project.

-The technical team will interact with the system in an indoor office through a computer terminal.

4f. Schedule Constraints

This will be determined through interviews with the board of directors and/or WFB operations and

management if the board wishes.

4g. Budget Constraints

This will be determined through interviews with the board of directors and/or WFB operations and

management if the board wishes.

5. Naming Conventions and Definitions

5a. Definitions of All Terms, Including Acronyms, Used in the Project

SRS – Software Requirements Document

Member – A user with an account with the WFB Airline booking system

Non-member – A user without an account with the WFB system

Flight Number – A unique number associated with each flight. Each flight number has an associated

departing and arriving city.

WFB – Wonderland Flight Booking

DRE – Data Retrieval Engine

5b. Data Dictionary for Any Included Models

Not known at this time.

6. Relevant Facts and Assumptions

6a. Facts

6b. Assumptions

We are assuming that the DRE can be developed independently, and will be ready for testing of the

system.

7. The Scope of the Work

7a. The Current Situation

This system is being built for a new company which had no system in place for this purpose.

Included here could be standardized airline practices.

7b. The Context of the Work

7c. Work Partitioning

8. The Scope of the Product

8a. Product Boundary

8b. Product Use Case List

8c. Individual Product Use Cases

9. Functional and Data Requirements

9a. Functional Requirements

The proposed system shall: - *Allow members to search for available flights, to reserve a seat, to book a flight, cancel a flight, and to edit

their member information

- allow non-member users to only search for available flights - *Require non-member users to create an account in order to reserve a seat or to book a flight -allow members to login using frequent flyer number as a username and require a sufficiently safe password -give users the option of linking their Google or Facebook accounts to their frequent flyer number, to simplify

login -check both the frequent flight number and password, when a user attempts to login -allow non-member users to enroll and to create a new account with the website -require the user to provide required information such as first name, last name, email address and password to

create a new account -allow only a password and signin to linked social media account -accept other optional information, such as phone number, credit card information and mailing address, during

the registration process -check if all required data are provided and then will prompt the user to enter additional information, if required -

auto-generate a unique frequent flyer number for the user after all required information is provided -allow the user to use this frequent flyer number as username for future authentications -accept data from a DRE implementing social media site’s APIs to retrieve user’s app data -provide users with the option of logging in with a variety of accounts -allow a logged-in user to purchase seats for an airplane flight -present the user with information on all (currently available) flights -allow the user to then select a pair (departure and return) of flights on which to purchase seats -allow the user to then indicate the number of seats and placement -guide the user completely through the checkout process -allow any customer to reserve a seat (closer to the front, window seat, aisle seat, etc.) once they have purchased

a ticket -indicate the seats to be reserved, initially found through the user’s previous bookings -display available seats for the departing and returning flights booked by the user -allow the user to select seats from each flight, where the number of selected seats from each flight is the number

that the user booked on that particular flight -allow the user to confirm the seat selection after selections are made -remove confirmed seat selections from available/unreserved seats and link the user’s booking to those particular

seats -assign the user randomly a seat from available seats 30 minutes prior to initial takeoff time if the user fails to

reserve a seat prior to flight takeoff -reduce the number of remaining seats by the number of tickets purchased as soon as purchase is confirmed -allow the user to return and use the function to book seats any time after up until 30 minutes prior their flight -provide the user a choice of available flights from which to pick -allow a user to query flight schedules based on simple input criteria -display the following information: Flight Number, Departing City and Date/Time, Arriving City and Date/Time,

Number of Available Seats when the user provides departure and arrival cities, and a departure/return date. -define a “matching” flight as one that uses the departure/arrival cities at a flight time greater or equal to the time

provided by the user -alert the user that no matching flights can be found, if none are found -allow customers to query the system to find flight information, even if they are not at an airport (e.g., on their

mobile phone) -allow the user – whether a member or not – to view flight information that matches input criteria. The user will

provide: 1-A Flight Number and Date; or 2-Departing/Arriving Cities and Date. -display matching flight information including: Flight Number, Departure City, Arrival City, and Status as one of

the following: In Flight, At the Gate, Delayed, or On Time. -display the number of remaining seats, if available -allow the user to modify their account information, including the power to view, edit, save, or delete the

information stored in the logged in account -allow a user to change or cancel a flight that is already booked and change his/her address, phone number, email

or password

-provide a way for the user to securely log out of the system -save all user operations when he/she exits the system -record the state of the user’s last search -retrieve the last state on the next login, and restore it -require a user wishing to continue accessing the website to log-in again to access user features

9b. Data Requirements

10. Look and Feel Requirements

10a. Appearance Requirements

10b. Style Requirements

11. Usability and Humanity Requirements

11a. Ease of Use Requirements

11b. Personalization and Internationalization Requirements

11c. Learning Requirements

11d. Understandability and Politeness Requirements

11e. Accessibility Requirements

12. Performance Requirements

12a. Speed and Latenency Requirements

12b. Safety-Critical Requirements

12c. Precision or Accuracy Requirements

12d. Reliability and Availability Requirements

12e. Robustness or Fault-Tolerance Requirements

12f. Capacity Requirements

If at any point the average time to run searches becomes greater than 5 seconds, new hardware must be

added to be able to decrease this time back below 2 seconds.

12g. Scalability or Extensibility Requirements

12h. Longevity Requirements

The system shall be designed to run uninterrupted on a weekly basis, with minimal downtime each

week for upgrades and maintenance.

The system shall be built to last at least 10 years, with the target being 20 years.

13. Operational and Environmental Requirements

13a. Expected Physical Environment

13b. Requirements for Interfacing with Adjacent Systems

13c. Productization Requirements

13d. Release Requirements

14. Maintainability and Support Requirements

14a. Maintenance Requirements

i) The software application is to be easily modifiable in the case the client needs further features.

ii) The application should notify users’ devices when they must update the application.

iii) The application shall be ready to be deployed on other OS.

14b. Supportability Requirements

i) * The application shall be available for Android, IOS, and Blackberry devices.

ii) * The application shall be available for both MacOS and Windows on desktops.

iii) The application shall be translated in various languages.

14c. Adaptability Requirements

15. Security Requirements

15a. Access Requirements

i) * All user data shall be kept confidential ii) Once the user is logged in, all communication shall be made through secure (encrypted) channels iii) The administrative control panel for the online booking system shall be accessed only by authorized

personnel. iv) Logged in users shall be able to access only their own data.

15b. Integrity Requirements

Only a selected few will have access to the maintenance of the database.

(To ensure that should there be a loss of information, there is a small pool of people who could have

leaked)

User data shall be backed up at a physically distributed site in case of system crash.

15c. Privacy Requirements

-No human shall have direct access to any user information since it will be stored in an encrypted

format. The formatting choices will be kept confidential to the programming team.

-Customers shall be notified of all information which they have a legal right to know.

-All privacy laws will be adhered to

15d. Audit Requirements

The system shall keep data from users who close accounts for 5-7 years.

(May be amended due to foreign regulations)

15e. Immunity Requirements

The system shall be built to withstand standard dos attacks.

The board of directors shall be advised of the option to contract out database security.

16. Cultural and Political Requirements

16a. Cultural Requirements

A brief investigation should be done as to whether any cultural differences are relevant in the design of

this particular system. If it is found that cultural requirements dictate part of our design, a possible

bifurcation should be explored, where two versions of the system are designed in parallel with similar

functionality, but a different end user interface.

The application should not display any offensive text or information.

16b. Political Requirements

No political requirements are known at this time.

When airline software regulations are released to us, we will follow them strictly.

17. Legal Requirements

17a. Compliance Requirements

-The application shall comply with all relevant information privacy acts.

-The application shall comply with all relevant airline regulations.

-The application will abide by all developer guidelines as denoted by Windows, Apple, etc.

-In general, all legal regulations will be strictly adhered to in the design, building, and final operations

of this system.

17b. Standards Requirements

-All legal regulations will be strictly adhered to in the design, building, and final operations of this

system.

18. Open Issues

-Meeting with WFB functional departments that are involved in this projects will determine if any additional

features are required. -It may be wise to determine through research if the majority of people use their computer or phone to

research/book flights. - this information is crucial to guiding our design optimization decisions.

19. Off-the-Shelf Solutions

19a. Ready-Made Products

No ready-made solutions exist for this, but we hope to be able to purchase or contract someone to build

us a DRE.

We may attempting to emulate similar applications’ functionality, to reduce the time needed to

design the app.

One simplification could be to use an off-the-shelf application for payment, or defer to credit

card companies to process payments.

19b. Reusable Components

19c. Products that can be Copied

We could make contact with competing organizations, and inquire as to what they might charge us for

the right to use components of their system.

20. New Problems

20a. Effects on the Current Environment

20b. Effects on the Installed Systems

20c. Potential User Problems

20d. Limitations in the Anticipated Implementation Environment That May Inhibit the

New Product

20e. Follow-Up Problems

21. Tasks

21a. Project Planning

21b. Planning of the Development Phases

22. Migration to the New Product

22a. Requirements for Migration to the New Product

22b. Data That Has to Be Modified or Translated for the New System

23. Risks

24. Costs

25. User Documentation and Training

25a. User Documentation Requirements

25b. Training Requirements

26. Waiting Room

Satisfaction of search requirements may not be necessary for initial testing.

The ability to select and purchase seats on a plane will not be required for initial deployment.

27. Ideas for Solutions

3RA3 Assignment #3 Solutions

November 27, 2017

Q2[6=3+3] From the list non-functional requirements given in thesample solution of Assignment #1, pick two for which in you opinion fit criteriaare necessary. Provide such fit criteria.

Statement #1: The application should provide an easy and clear page forusers to login and sign up.

Fit Criteria #1.1: The login page shall allow 85% of the users to success-fully complete the login within 45 seconds from the time they land on that page.

Fit Criteria #1.2: The sign-up process shall allow 85% of the users tosuccessfully complete the registration with no more than extra five (5) naviga-tional movements. Mandatory fields should be kept at a minimum (user-name== email, password), with optional fields that can be updated at any time aftersign-up.

Statement #2: The application shall make it easy for the average user tolocate available flights.

Fit Criteria #2: 90% of the users shall be able to search for flights fromany page in no more than three (3) navigational movements. The list of availableflights shall enable filtering (and sorting) by multiple criteria: date of the flight,time of day, airline, number of stops, price, etc. Each criteria shall be easilychanged (and the search updated) from the result page (user shall not have to“go back” or make additional page changes to arrive at the search criteria).

1

Q3[8] Build an entity-relationship diagram to declare and structure thedata of the system.

Q4[8=4+4] Represent the information flow of the system through adataflow diagram. Start with a context diagram and then expand it to a fulldataflow diagram.

2

3

4

Q5[5] Represent system operations by use case diagram.

5

Q6[5] Build a state machine diagram

6

Q7[12=3+3+3+3] Represent all four scenarios from the postedsolution to Assignment 1 by activity diagrams

7

8

9

Q8[10]

(a) The doors must be able to open when the elevator is fully arrived at eachfloor of the hotel.

ELEV ATORS : set of all elevatorsFLOORS : set of all floors (Integer)DOORSTATES : {Open,Closed,Available}

fullyArrived : ELEV ATORS × FLOORS → {true, false}doorStatus : ELEV ATORS → DOORSTATES

∀f ∈ FLOORS ∀e ∈ ELEV ATORSfullyArrived(e, f) == true⇒ doorStatus(e) = ”Available”∀e ∈ ELEV ATORSdoorStatus(e) == ”Available”⇒ doorStatus(e) = ”Open”∀f ∈ FLOORS ∀e ∈ ELEV ATORSfullyArrived(e, f) == false⇒ doorStatus(e) = ”Closed”

(b) Floor buttons will illuminate immediately when they are pushed, andwill turn off immediately upon the elevator stopping at the indicated floor.

FLOORS : set of all floors (Integer)

floorsPressed : set of all floors pressedatF loor : FLOORS → {true, false}buttonPress : FLOORS → {true, false}illuminateButton : FLOORS → {true, false}

∀f ∈ FLOORS buttonPress(f) ∧ ¬atF loor(f)⇒floorsPressed′ = floorsPressed ∪ {f} ∧ illuminateButton(f) = true∀f ∈ FLOORS illuminateButton(f) = true ∧ atF loor(f)⇒floorsPressed′ = floorsPressed\{f} ∧ illuminateButton(f) = false

(c) In the case of any hotel wide emergency system activating (eg fire alarm)all elevators go to “out of service” status.

ELEV ATORS : set of all elevatorsSTATE : set of all elevator state = {outOfService, inService}isEmergency → {true, false}elevState : ELEV ATORS → STATE

isEmergency == true⇒ ∀e ∈ ELEV ATORS elevState(e) = ”outOfService”

10

Q9[8] Which part of the WFB you would consider as safety critical? Jus-tify your choice and provide a model of this part using plain predicate calculus

A safety issue could be the unauthorized access to personal user information.The system should have countermeasures in place, and they should be acti-vated. This is modeled by a pair of domain (countermeasureState) and system(CountermeasureActivated) variables. Similarly, a security breach is modeledthrough a pair of domain (securityState) and system (SecurityBreached) vari-ables.

countermeasureState→ {Active, Inactive}securityState→ {Breached, Unbreached}CountermeasureActivated→ {true, false}SecurityBreached→ {true, false}UserInfoIsSafe→ {true, false}

countermeasureState = Active⇔ CountermeasureActivated = truecountermeasureState = Inactive⇔ CountermeasureActivated = falsesecurityState = Breached⇔ SecurityBreached = truesecurityState = Unbreached⇔ SecurityBreached = false

CountermeasureActivated⇒ UserInfoIsSafe¬CountermeasureActivated ∧ ¬SecurityBreached⇒ UserInfoIsSafe¬CountermeasureActivated ∧ SecurityBreached⇒ ¬UserInfoIsSafe

Q10[6=2+2+2] Express the following statements in Linear Tempo-ral Logic:

1. A passenger entering the elevator at 5th floor and pushing 2nd floor but-ton, will always reach 2nd floor, even if she/he entered an upwards travel-ling elevator. In this case you might use the following atomic predicates:floor=2, direction=up, direction=down,ButtonPres2, f loor=5, etc

�((floor=5 ∧ ButtonPressed2 ∧(direction=up ∨ direction=down))⇒♦floor=2)

2. It is impossible to get a state where started holds but ready does not hold.started and ready are atomic predicates

�(start⇒ ready) ≡ �¬(start ∧ ¬ready)

3. For any state, if a request (of some resource) occurs, then it will eventuallybe acknowledged. request and acknowledged are atomic predicates.

�(request⇒ ♦acknowledged)

11

Q11[8+4 (bonus)] For which aspects of the WFB, SCR tables arethe most useful?

SCR table would be the most useful for the functional aspects of the WFBsystem. SCR tables are particularly useful for the functional aspects becausethe functional aspects of the system activate only under certain conditions.SCR tables are able to show these conditions, which make them optimal forrepresenting functional requirements for the WFB system.

12