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 tamanga13@students.ecu.edu apil.tamang
Sana, Anish sanaa14@students.ecu.edu anish220
Ojo, Oludare Mercy ojoo13@students.ecu.edu oludareojo
Alluri, Aparna alluria14@students.ecu.edu aparna.alluri
Brinson, Chrystal Edwards brinsonch14@students.ecu.edu chrys_jean
Clark, James Alan clarkj12@students.ecu.edu 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
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:
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

Recommended

Recommended

More Related Content

What's hot

What's hot (13)

Viewers also liked

Viewers also liked (14)

Similar to SENG 6270 - Software-Requirement-Specifications

Similar to SENG 6270 - Software-Requirement-Specifications (20)

SENG 6270 - Software-Requirement-Specifications