SENG 6270 - Software-Requirement-Specifications

Software Requirements Specification SENG 6270 Group Project

Group 1

Anish Sana Aparna Alluri Apil Tamang

Chrystal Edwards Brinson James Alan Clark

Oludare Mercy Ojo East Carolina University Spring 2015

Contents

Contents ........................................................................................................................................................ 2

List of Figures ................................................................................................................................................ 3

List of Tables ................................................................................................................................................. 4

1 – Introduction ............................................................................................................................................ 5

1.1 – Purpose ............................................................................................................................................ 5

1.2 – Scope of project ............................................................................................................................... 5

1.3 – Glossary ............................................................................................................................................ 5

1.4 – References ........................................................................................................................................ 6

1.5 – Overview .......................................................................................................................................... 6

2 - Overall Description .................................................................................................................................. 6

2.1 – Product Perspectives ........................................................................................................................ 6

2.2 – Product Functions ............................................................................................................................ 7

2.3 – User Characteristics ......................................................................................................................... 7

2.4 – Constraints ....................................................................................................................................... 8

2.5 – Assumptions and Dependencies ...................................................................................................... 8

3 - Specific Requirements ......................................................................................................................... 8

3.1 – External Interface Requirements ..................................................................................................... 8

3.1.1 – User Interfaces .......................................................................................................................... 8

3.2 Functional Requirements .................................................................................................................. 11

3.2.1 – Common Functions ................................................................................................................. 12

3.2.2 – Mode 1 .................................................................................................................................... 14

3.2.3 – Mode 2 .................................................................................................................................... 16

3. 3 – Behavior Requirements ................................................................................................................. 18

Appendices .................................................................................................................................................. 20

Meeting Minutes ..................................................................................................................................... 20

February 7, 2015 ................................................................................................................................. 20

February 10, 2015 ............................................................................................................................... 24

February 17, 2015 ............................................................................................................................... 26

List of Figures

Figure 1 – Use case diagram for photo reprint ............................................................................................. 7

Figure 2 – Class Diagram for Photo Reprint .................................................................................................. 7

Figure 3 – Prototype without requirements (View 1) ................................................................................. 10

Figure 4 – Prototype without requirements (View 2) ................................................................................. 11

Figure 5 – State diagram ............................................................................................................................. 18

Figure 6 – SRS Template .............................................................................................................................. 21

Figure 7 – Task delegation in Google Drive ................................................................................................. 23

List of Tables

Table 1 - Glossary .......................................................................................................................................... 5

Table 2 – Team members’ information for 2/7/15 ..................................................................................... 20

Table 3 – Team members’ information for 2/10/15 ................................................................................... 24

Table 4 – Example Heterogeneous order ................................................................................................... 26

Table 5 – Example Homogenous Order ...................................................................................................... 26

Table 6 – Team members’ information 2/17/15 ........................................................................................ 27

1 – Introduction

This section will give the description of the purpose and scope of the project, overview of everything

included in this document. Also the definitions, acronyms, and abbreviations used in this document are

provided. The document was created in accordance to the IEEE standards [1].

1.1 – Purpose

The purpose of this document is to give a detailed description of the requirements for the “Reprints

Ordering System” [2]. It explains the purpose of the system, the various interfaces and constraints of the

system. This document is primarily intended to be proposed to the customer Dr. Vilkomir for his approval

and can be used as a reference by the developers for the development of the first version of the system.

1.2 – Scope of project

This software is a “Reprints Ordering Systems” that allows customers to order reprints of photographs.

The system will organize the order and calculates the price of the order based on various attributes like

reprint quantity, size, finish and processing time.

1.3 – Glossary

The glossary was created in accordance with IEEE standards [3].

Table 1 - Glossary

Term Definition

Software Requirements Specification (SRS)

A document that completely describes all of the functions of a proposed system and the constraints under which must operate. For example, this document.

Customer Customer is a person or organization that purchases the software but may or may not actually use it.

IEEE-The Institute of Electrical and Electronics Engineers, Inc.

It is a professional organization whose objectives are the educational and technical advancement of electrical and electronic engineering, telecommunications, and computer engineering and allied disciplines.

GUI-Graphical User Interface

It is a type of interface that allows users to interact with electronic devices through graphical icons rather than text commands.

User A person who will be working on the software after it is completed.

Prototype An application that illustrates or demonstrates some aspects of an application that is under construction.

Stakeholder Any person with an interest in the project who is not a developer.

Functional requirements A requirement expressing a function which an application must perform.

Constraints A specified limitation.

1.4 – References

[1] IEEE, IEEE Recommended Practice for Software Requirements Specifications, vol. 1, 1998, p. 40.

[2] S. Vilkomir, Lecture 5, Greenville, North Carolina: East Carolina University, 2015, pp. 2-25.

[3] IEEE, IEEE Standard Glossary of Software Engineering Terminology, vol. 1, 1990, p. 84.

1.5 – Overview

This document describes a Reprints Ordering System application that will be windows based. The

application will have a grid-view to display ordered reprints, specifications for each and the costs. Users

will be able to use this software to pick sizes of reprints, paper, and the number of reprints. Users will

also be able to choose to have next day or 1-hour reprinting.

2 - Overall Description

The application to be developed is a windows/web form that will have a grid view to display ordered

reprints and respective costs.

It will have a single front end interface that an end user will use in inputting new requests for a customer

and a reports page for checking /reviewing request history.

Details of the requests are displayed on a grid view and can be downloaded in excel.

2.1 – Product Perspectives

The product being built aims to develop and test software for ordering reprints at a photo center. It

automatically recalculates amounts due based on the quantity of photo reprints ordered for.

Discount is given to customers once particular thresholds are met (as described in the later sections of

this document.)

2.2 – Product Functions

Figure 1 – Use case diagram for photo reprint

Figure 2 – Class Diagram for Photo Reprint

2.3 – User Characteristics

Users of the photo reprinting software will have the following characteristics -

a) Be able to order photo reprints.

b) Understand the ordering process.

c) Validate the price calculated by the software.

d) Provide requirements for design.

e) Provide reprint quantities.

f) Provide reprint size.

g) Select a finish.

h) Choose processing time.

i) Choose from a range of possible choices for sizes, finish and processing time.

j) Understand the pricing of photo reprints based on the choices made.

k) Understand the discount policy.

l) Be able to use the software interface.

On the other hand, users should not have to -

a) Understand detailed specifications of the software.

b) Understand code.

c) Understand testing documentation.

d) Understand the tests performed to ensure proper working of the software.

2.4 – Constraints

The following constraints will be levied by the software on the user -

a) The user can select a minimum of 1 reprint and a maximum of 100 reprints.

b) The user has to select one of the following sizes - 4x6, 5x7, and 8x10.

c) The user has to choose between a matte and a glossy finish.

d) The user can choose a processing time of 1 hour or the next day.

2.5 – Assumptions and Dependencies

The following assumptions are made -

a) The user has a reasonable level of computer proficiency.

b) The user has relative knowledge of photo reprint sizes available.

c) The promotional code is a valid code that the system is able to identify.

3 - Specific Requirements

3.1 – External Interface Requirements

3.1.1 – User Interfaces The overall description of the application is a single screen that will allow users to add, enter, and edit an

order and finalize the transaction with payment. The system shall provide a method of taking a reprint

order consisting of one or more multiple reprint types, editing that order, and finalizing the order by

applying various discounts and added costs. The User Interface will also have a receipt area where the

price is being calculated in real time, as it is entered like at grocery store. Following the grocery store

model, apply discounts at end.

a) Name of item: Main Window

b) Description of purpose: The main data entry and reporting screen, all user interaction and feedback will be through this screen.

c) Source of input or destination of output: Source of input is the user and destination is a final

receipt listing the order details.

d) Valid range, accuracy, and/or tolerance:

i. The reprint entry fields for the number of reprints will accept values from 0 to 100. In aggregation all entry fields together will not allow a count over 100.

ii. The coupon code field will verify valid inputs.

e) Units of measure: User will enter integers that represent a simple count of reprints.

f) Timing: None

g) Relationships to other inputs/outputs: None

h) Screen formats/organization: The screen will have order information on left with several buttons and entry fields, on the right will be a receipt area showing the order details.

i) Window formats/organization: There will be only one window.

j) Data formats: Entry fields will only consist of integer entries.

k) Command formats: None

l) End messages: The finalize order button will display a message for successful completion.

User Interface Components

UI-1: Button Start Order

The GUI shall contain a button to begin an order transaction

UI-2: Button Calculate Order

The GUI shall contain a button to calculate the total cost of order as it is currently entered. This allows an

opportunity for further changes, application of discounts, removal of discounts, etc.

UI-3: Button Finalize Order

The GUI shall contain a button to finalize an order. This symbolic step represents the exchange of cash or

credit card information.

UI-4: Text Area Receipt

The GUI shall contain a text area to display the receipt of the current order.

UI-5: Text Area Process Step

The GUI shall contain visual indicators of what processing step the application is in: Ready to take Order,

Entering Order, Calculating, and Finalizing.

UI-6: Order Entry Grid

The GUI shall contain a grid to enter the order allowing for all permutations of Size, Count, Finish, and

Time.

UI-7: Label Total Count

The GUI shall contain a display of the total count of reprints entered in UI-6, which will be updated as UI-

6 grid is updated.

UI-8: Text Entry Field for a Discount Code

The GUI shall contain a field to enter a discount code.

UI-9: Button Cancel Order

The GUI shall contain a button to cancel any order that is in progress

UI-10: View Default Pricing

The GUI shall contain a set of Read-Only fields to display the pricing ranges for all types and permutations

of calculating price.

Figure 3 – Prototype without requirements (View 1)

Figure 4 – Prototype without requirements (View 2)

3.2 Functional Requirements

The functional requirements are –

a) Validity checks on the inputs

b) Exact sequence of operations

c) Responses to abnormal situations, including –

i. Overßow

ii. Communication facilities

iii. Error handling and recovery

d) Effect of parameters

e) Relationship of outputs to inputs, including –

i. Input/output sequences

ii. Formulas for input to output conversion

3.2.1 – Common Functions

FR-1: Grid Entry Validation

Summary: The grid entry form will only be for entering a count of reprints. These fields can only accept

integers.

Rationale: This application is calculating price on a simple count, there is no reason to allow any other

input except integers between 0 and 100.

Requirements: The application shall only allow count entry fields to accept integers between 0 and 100.

References: UI-6

FR-2: Discount Code Validation

Summary: The application allows the entry of a discount code that will be applied to an order and must

be verified.

Rationale: The applying of incorrect codes to an order could give people discounts when they are not

allowed. The discount code must be checked against a set of known and valid codes.

Requirements: The application will only allow entry of valid discount codes, which will require that the

application contain a list of known valid codes that will be used to compare to the entered code. The field

will be 30-character alphanumeric with no special characters.

References: UI-7

FR-3: Start Order

Summary: This beginning step in the order process, clicking the button begins an order transaction.

Rational: The user needs to start somewhere; this will clear the system and re-set the screen components.

Requirement: When this button is hit, the application will reset all components of the UI, they will be

cleared or set to default values. At the start of the order, the system will clear grid and set the reprint

type selections to the default values.

References: UI-1 Button Start Order

FR-4: Order Entry

Summary: The order is entered by typing in integers into the entry grid. During this time, the receipt is

being generated to show current total

Rational: The user must enter an order. This covers the behavior of the application during the order entry

state. Fields are being entered, the receipt is being updated. This allows the user and customer to see

what the current price is as it is being entered.

Requirement:

The system through the data grid shall provide a method of selecting all permutations of a Reprint:

including Size, Finish and Processing Time and Quantity.

When a field in the grid is edited, then the application will calculate the new total and display update d

receipt.

When a field in the grid is edited, then the total count display will be updated to show new current total

count.

References: UI-6, UI-4, UI-7

FR-5: Discount Code Entry

Summary: This application allows for the entry of a discount code to apply to the order. The code must be

entered, verified, and applied.

Rational: This is needed as a customer requirement to allow discount codes.

Requirement: At any time in order the user may enter the discount code. On entry of the code the

application must verify that it is a valid code by comparing to known codes.

If the code is valid, the text field will turn green and the discount calculation will be applied.

If the cod is not valid, the text field will turn red and the discount will not be applied.

There is no requirement to clear the code if it is red. It will simply not be applied, the receipt will reprint

that it was an invalid code. This field is cleared along with other fields when the order is complete.

References: UI-8

FR-6: Click Calculate Order

Summary: For pricing, the system shall determine if the order is Uniform or Heterogeneous by the number

entry of Order Types. The “Store Clerk” does not need to select one or the other; it is already known by

the Reprint Types entered. If there is only one reprint type, automatically uniform, if 2 or more,

automatically heterogeneous.

The calculations themselves are covered in Requirements Mode 1 and Mode 2. This requirement is just

to describe the UI reaction to re-calculating the order.

Rational: The user which is entering the order may be requested by the user to give an updated price or

to see a list of the order up to this point. The customer ordering the reprints may be listing a long order

and want an update on where it is currently mid-way through the entry.

Requirement: When this button is clicked the currently entered order will be re-listed to the receipt box

and all calculation applied showing any discounts.

References:

FR-7: Click Finalize

Summary: In a cashier, system there comes a point to make the final payment. This finalize button is

simulating this final step. The order is complete, cash is exchanged, and there are no more edits allowed.

Rational: This is the point when the customer is handing cash to the teller and the order is final.

Requirement:

Final receipt of the order is reprinted to receipt screen. Final Recipe shows all entries, total, and all

discounts applied.

All UI components are cleared or set back to a default value.

References: UI-3, UI-4

FR-8: Click Cancel order

Summary: This will abort the current order and clear all entries, and set UI back to default.

Rational: The customer of the photo store may at any time change their mind and walk away. There is a

need to reset system back to the starting point.

Requirement: When the Cancel order is hit then the UI will return to default and any information about

the partial order is deleted.

References:

FR-9: Receipt Update

Summary: The application shall display a running total based on standard prices. As reprint orders are

added, the receipt will show the running total.

Rational: Users are accustomed to many cashier systems showing an updated receipt total as the order is

entered. This is becoming a user expectation. This application will accommodate as a standard user

expectation.

Requirement: When the order grid is updated, the change will be reprinted to the receipt area.

References:

FR-10: Default Pricing Display

Summary: Customers as well as the photo teller may want to see what the user will pay. This screen will

show this information.

Rational: The application will be applying pricing calculations to the order, users and customers may have

a dispute over what something costs. The business logic, including brackets and pricing, will be displayed

so there is no doubt.

Requirement: This pricing screen is a read only screen that will show the current values held in the system

that is being applied to the order.

References:

3.2.2 – Mode 1 Calculation of final cost for an order involving reprints with same size, finish, and processing time –

Summary: In this section, we list the business rules by which the final cost for an order is calculated based

on the number or reprints involved.

Rational: The specifications are retrieved from the corresponding requirements terms from the contract.

Requirement: The following set of rules apply only if all the reprints in an order is of a uniform size, finish,

and processing time.

References: Contract.

3.2.2.1 – For reprints with sizes 4x6

Summary: The following rules apply if the order is for reprints with sizes 4x6.

FR-1 Order <= 50 reprints

The software shall charge $0.14 per reprint for the first 50 reprints.

FR-2 50 reprints < Order <=75 reprints

The software shall charge $0.12 per reprint for reprints after 50 and before or equal to 75.

FR-3 75 reprints < Order <=100


FR-4 Matte finish

The software shall charge an additional $0.02 per reprint if the finish is matte.

3.2.2.2 – For reprints with sizes 5x7








FR-4 Matte finish.


3.2.2.3 - For reprints with sizes 8x10








FR-4 Matte finish


3.2.2.4 – Price for 1-hour processing.

Summary: The following rules apply if the order is for 1-hour processing time, in addition to the order

being for reprints of uniform size and finish.


The software shall add $1.00 to the final cost if the order is for less than or equal to 60 reprints.

FR-2 Order > 60 reprints

The software shall add $1.50 to the final cost if the order is for more than 60 reprints.

3.2.2.5 – Calculating discount on final price.

Summary: The following rules apply if the order is for uniform size, finish, and processing time.

FR-1 Qualifying discount with maximal reprints order

If the number of reprints is equal to 100, and the customer offers the promotional code: N56M2, the

software shall give the option of applying a $2.50 discount on the final price.

FR-2 Qualifying discount with total cost >= $35

If the total cost is greater than or equal to $35, the software shall give the option of applying a 5% discount

on the total price.

FR-3 Applying a qualifying discount

The software shall allow the user to choose one of the qualifying discounts from 3.2.2.5-FR-1 and 3.2.2.5-

FR-2.

3.2.3 – Mode 2 Calculation of final cost for an order where the size, finish and processing time for each reprint is specified

separately –

Summary: In this section, we list the business rules by which the final cost for an order is calculated based

on the number, size, finish, and processing time of the reprints involved.

Rational: The specifications are retrieved from the corresponding requirements terms from the contract.

Requirement: The following set of rules apply if the attributes of the reprints were set individually by the

customer.

3.2.3.1 – Reprint with size 4x6

Summary: The following requirements apply if the reprint is of size 4x6.

FR-1 Price per reprint

The software shall charge $0.19 per reprint with size 4x6.

FR-2 Matte finish

The software shall add an additional amount of $0.04 if the finish is matte.





FR-2 Matte finish






FR-2 Matte finish


3.2.3.4 – Price for 1-hour processing

Summary: The following rules apply if the order is for 1-hour processing time, in addition to the order

being for reprints whose attributes where chosen separately.


The software shall add $2.00 to the final cost if the order is for less than or equal to 60 reprints.

FR-2 Order > 60 reprints

The software shall add $2.50 to the final cost if the order is for more than 60 reprints.

3.2.3.5 – Calculating discount on final price.

Summary: The following rules apply if the order is for reprints whose attributes were chosen separately.

FR-1 Qualifying discount with total cost >= $35

If the total cost is greater than or equal to $35, the software shall give the option of applying a 5% discount

on the total price.

FR-2 Applying a qualifying discount

The software shall allow the user to apply the qualifying discount from 3.2.3.5-FR-1.

3. 3 – Behavior Requirements

Overview state diagram of the sequences the user and application goes through during the processing of

an order.

We include here a simple overview Use Cases to describe the basic flow of a user’s interactions with the

system.

Figure 5 – State diagram

UC-1: Start a New Reprint Order

Use Case Name:

Start a New Reprint Order

Brief Description:

This simple application has one main Use Case, the taking of an order.

The basic description is that a Reprint Shop attendant will take a customer’s reprint order by entering the

number and type of reprints desired. The sequence of operation is Begin Order, Enter Order, Edit Order,

Calculate, and Finalize.

Scope:

The Main Window

Level:

User Goal

Primary Actor:

Reprint Shop Attendant

Stakeholders and Interests:

Reprint Shop Attendant: Wants to enter orders, see updates to edits, be able to perform any re-

calculations and finalize the order.

Preconditions:

The application is not already in a state of taking an order. The application must be in the Not-Active state

before beginning an order.

Success Guarantee:

The Reprint Shop Attendant can successfully enter a full order and finalize the order.

Main Success Scenario/Flow of Events:

a) Attendant clicks the button (UI-1: Button Start Order) which begins the transaction.

b) Attendant begins entering order information as customer describes the desired number and type

of reprints. The order information is typed into the order grid. (UI-6: Order Entry Grid)

c) The customer completes telling the order and Attendant is done entering the order.

d) Customer can choose to have receipt re-reprinted, a fresh copy, and review.

e) Customer chooses to pay, the attendant takes money and hits Finalize button.

Alternate Paths:

a) At any time the user can re-quest a re-reprint, re-calculate. Attendant can click re-calculate if the

customer would like to see an updated total.

b) At any time the user may present their discount code. At any time the Attendant can enter a

discount code.

c) At any time the Customer can change their mind and leave. The attendant would then hit Cancel.

Special Requirements:

Use Case/VOPC Diagram

Appendices

Meeting Minutes

February 7, 2015 Meeting Data:

Date of Meetings: Feb 7, 2015

Duration: 2 hours

Team members: 6

Team Members (Full names)

Table 2 – Team members’ information for 2/7/15

Name Email Skype

Tamang, Apil [email protected] apil.tamang

Sana, Anish [email protected] anish220

Ojo, Oludare Mercy [email protected] oludareojo

Alluri, Aparna [email protected] aparna.alluri

Brinson, Chrystal Edwards [email protected] chrys_jean

Clark, James Alan [email protected] j7m7scl7rk

Team Members Present:

Everybody attempted to join

Meeting staff (rotated among group members at least every two weeks):

Facilitator: Apil Tamang

Recorder: James Clark

Discussion

General Introductions –

Apil – on campus, this is last class, also doing thesis. Learning WPF recently.

Chrystal – online, teacher. New to programming.

James – online. This is last class, and doing thesis. 15 years’ experience with process control

Anish – on campus. Masters in mechanical engineering, and now doing second masters in Software

Engineering. New to programming.

Agenda

Document is due Feb 18.

a) Software Requirement Specification (SRS)

b) Software description for class project.

Discussion on SRS

Group reviewed last three lectures 5, 6, 7 concerning project requirements and what is needed in SRS.

There was wide ranging discussion on how to group requirements, by Use Case, by Feature, Mode, etc…

Group decided to group requirements based on functional requirements by mode, shown in IEEE 830-

1998 appendix A.1.

Figure 6 – SRS Template

PowerPoint Requirements to Group SRS.

Group then discussed all customer requirements as listed in lecture PowerPoint’s.

Preliminary decisions on modes would be Discount, Homogeneous orders, and Heterogeneous orders.

There was wide ranging discussion on what constitutes a mode. It was decided that size, finish, and time

are not modes, but are properties of the modes. Each of these properties will have unique requirements

based on modes.

Requirements by mode

Time

Discount: Coupon/ Order > 35$

Can’t combine discounts

Give customer a display to show which discount is best.

Order was all same uniform, or mixed.

Homogenous – Size, finish, time

Heterogeneous – Size, finish, time

Size

35$ > 5% reduction. But not with coupon. (Would this be a mode, or subset of Coupon?)

Matte/Glossy

There was discussion on what questions to ask Professor, deemed (Professor as Instructor and Professor

as the Software Customer)

Questions (To Professor as Instructor)

Apil will ask Professor in class if we are even in the right ballpark with this kick off meeting.

Questions (To Professor as Software Customer)

Noted that writing requirements are an iterative process with a customer and we will need to interview

the Professor as he plays the role of customer. The requirements as presented in the power point are a

rough estimate, a first pass at what a customer wants. As we define details and work through building an

application, we will need input. We will be planning to have our questions as SW developers ready to

question the professor in some group setting. We need to be well prepared, like a presentation, almost

like presenting to a customer a proposed solution to get their feedback. (Question, time TBD, does this

need to happen before Feb 18th, probably)

Potential Questions group discussed

Price based on count

Does the Price, shown on Slide 13, change for all pictures, or in the ranges displayed. Does the price change

for each range cumulative, or does the price change for all. Example, if there are 80 pictures, do all 80 cost

.28, and NOT priced in ranges with 0-50 at .34, 50-75 at .31 and 75 – 80 at .28. We do NOT need to add

up a different cost for each range; it is really that once a level is reached, then all pictures cost that lower

price.

GUI Entry Fields

On the subject of reprint ranges (0-100) and pricing. How would the customer like to enter the number of

pictures from 0-100? Would a drop down box of 0-100 be too cumbersome, or will typing in a number

lead to typos? A text entry box could allow a user to enter a number between 0-100 and it be a typo.

However, a drop down for 100 would be very long. Alternatively, are modern drop down boxes convenient

enough. This is TBD with GUI usability requirements influenced by tool choice.

GUI – drop down for 0-100. Alternatively, text box checking for valid.

GUI validation.

A feature that a customer might like on discounts

NOTE: make app show which discount is best coupon, or >35$.

On a note of collaboration, would the customer like a screen to show which is the greater discount, the

coupon or the over 35$ discount. They cannot both be used, so customer might want to choose which will

save more.

Group Assignments

Chrystal has set up file on Google Drive with the general SRS outline with 3 sections.

There are six people our in-group and it was logical to break the 3 sections up by twos.

These assignments are posted in the Google Drive.

Figure 7 – Task delegation in Google Drive

Next Steps

Next group meeting is Tuesday at 8.

Everybody to have first draft of section so group can review.

We plan to have first drift, and the next week of compiling requirements document, to prepare for a group

interview with Professor (as Software Customer).

February 10, 2015

Date of Meetings: Feb 10, 2015 Duration: 1 hours Team member 6


Table 3 – Team members’ information for 2/10/15

Name Email Skype








Ojo unable to attend


Facilitator: Apil Tamang

Recorder: James Clark

Discussion

Agenda –

Apil review Professors comments on Functional Requirements

Discuss the Reprints / Cost Plateaus and Company/customer impact.

Review SRS Standard sections

Document is due Feb 18.

Discussion on SRS Modes

Professor liked the original Modes as described in first MM, Homogenous, Heterogonous, and discount as

in Apil’s doc.

But not the discount mode, he felt that it was a common function, or parts should be spread to the other

2 modes.

In Apil’s functions the Discount mode, Mode 3.1 is unique to Mode 1 Homogeneous. That would be one

move.

Another suggestion was to change the wording of the discount mode to make it more explicitly a separate

step in the process.

3rd mode: Just change wording to not be applying discount as order is entering, but only at end as a

separate step.

(Apil / James) Perhaps do quick re-touch up showing Mode 3 as a separate step in a Use Case and see if

that changes opinion. In any case, there did not seem to be problem with only having two modes.

(Although, if we go to the Grid data entry entering/editing would then become one step, no differentiation

until the finalize button is hit). James desired modes for Entry/Editing but those would be negated by new

UI shown below.

Reprint Count Bracket Discount Discussion

Professor left this open to group. There was good discussion mixing the balance of customer earning more

money versus potentially having repeat customers. Should the discount apply to entire order (of that

type)?

Professor desired a group vote.

How to calculate price discussion concerning plateau points. Professor desired to have our group vote.

Apply discount to total order versus company making more per order. By giving customer discount, could

lose dollar, but gain repeat customer.

Anish – Vote all same price.

Aparna – Vote all same price.

Apil – Vote separate prices. If Seller sells 51 reprints then they get a discount for all 51.Compelling

argument.

James – Vote all same price. .12 * 51, not .14 * 50 + .12 * 1.

Chrystal - Vote all same price.

Decision was discount to apply to all, not the brackets.

The Company will not make as much money on each order, but customers ordering reprints would have

incentive to order more, and feel good about a discount.

Not a mode, but a feature, show a running total of the count discounts with a look ahead that will display

to customer how much they could save if they ordered a few more. Given this feature, if a customer is

prodded into ordering more reprints, then the company will make more than if the customer had not.

(Maybe bonus feature for sales/marketing would be to actually track this additional amount, would need

to have cashier trigger that an additional count was added after the prodding).

UI/Data Entry

Aparna suggestions for UI

A grid with top row reprint size, and left column are the other properties, matt, time.

A grid can cover every entry case, and allows for editing and changing order multiple times.

Cashier could change any number and re-hit Finalize to reprint a new Receipt. At this point, because all

fields can be entered at once time, then the calculations/discounts can all is applied at same time. Perhaps

an additional field for discount code, and potential display showing saving if customer order s up to next

count bracket.

Table 4 – Example Heterogeneous order

Table 5 – Example Homogenous Order

Next Steps

Draft is due from group members to Apil on Friday. Provide time for Apil to compile into one and then for

group to review.

Suggestion that we rotate compiling final draft of document.

Apil volunteered for this first one SRS for Feb 18.

James - Add Use Cases under Behavior

Add some Non-Functional Requirements (James and Apil to decide on a few).

Group went through and discussed each section of SRS to insure alignment in-group.

February 17, 2015 Meeting Data:

Date of Meetings: Feb 17, 2015

Duration: 45 minutes

Team members 5


4x6 5x7 8x10

Matte 30 5 10

Time Next-Day

4x6 5x7 8x10

Matte 100

Time

Table 6 – Team members’ information 2/17/15

Name Email Skype








Everybody except James was able to make it to the meeting. James anticipated that he would be

unavailable at this time because of traveling requirements with his work.


Facilitator: Anish Sana

Recorder: Apil Tamang

Discussion

Agenda

Final review on SRS document slated for submission on Feb. 18

Discussion on SRS

We reviewed materials on the SRS and put up any questions we may have had. Chrystal wasn’t sure how

to define “mode” as it appeared on the SRS. She mentioned that despite looking at multiple references,

she was unable to find a satisfactory definition of the term. Apil wasn’t sure if we needed to use the word

‘print’ or ‘picture’ or ‘reprints’ in the context of the application. They all surfaced as each responsible

member went on to work on the SRS. We finally agreed to settle on ‘reprints’ as the choice of word, and

further agreed that all of them referred to essentially the same product in the business scenario.

Next Steps

Next group meeting is Tuesday, Feb 25th at 8PM. We may try to do an early meeting on the weekend to

get a head start on the implementation, which is due on March 7, 2015.

SENG 6270 - Software-Requirement-Specifications

Documents

Transcript of SENG 6270 - Software-Requirement-Specifications