object oriented analysis and design.
requirement analysis.
what is requirement?
types of requirement.
functional requirements.
nonfunctional requirements.
The customer will typically be required to provide or choose a billing address, a mailing address, a delivery option, and payment details like a credit card number. As soon as the order is placed, a customer notification email is delivered.
object oriented analysis and design.
requirement analysis.
what is requirement?
types of requirement.
functional requirements.
nonfunctional requirements.
The customer will typically be required to provide or choose a billing address, a mailing address, a delivery option, and payment details like a credit card number. As soon as the order is placed, a customer notification email is delivered.
Software Requirements Specification
for
<Project>
Version 1.0 approved
Prepared by <author>
<organization>
<date created>
Table of Contents
TOC \o "1-2" \t "TOCentry,1" Table of Contents
PAGEREF _Toc441230970 \h ii
Revision History
PAGEREF _Toc441230971 \h ii
1.
Introduction
PAGEREF _Toc441230972 \h 1
1.1
Purpose
PAGEREF _Toc441230973 \h 1
1.2
Document Conventions
PAGEREF _Toc441230974 \h 1
1.3
Intended Audience and Reading Suggestions
PAGEREF _Toc441230975 \h 1
1.4
Product Scope
PAGEREF _Toc441230976 \h 1
1.5
References
PAGEREF _Toc441230977 \h 1
2.
Overall Description
PAGEREF _Toc441230978 \h 2
2.1
Product Perspective
PAGEREF _Toc441230979 \h 2
2.2
Product Functions
PAGEREF _Toc441230980 \h 2
2.3
User Classes and Characteristics
PAGEREF _Toc441230981 \h 2
2.4
Operating Environment
PAGEREF _Toc441230982 \h 2
2.5
Design and Implementation Constraints
PAGEREF _Toc441230983 \h 2
2.6
User Documentation
PAGEREF _Toc441230984 \h 2
2.7
Assumptions and Dependencies
PAGEREF _Toc441230985 \h 3
3.
External Interface Requirements
PAGEREF _Toc441230986 \h 3
3.1
User Interfaces
PAGEREF _Toc441230987 \h 3
3.2
Hardware Interfaces
PAGEREF _Toc441230988 \h 3
3.3
Software Interfaces
PAGEREF _Toc441230989 \h 3
3.4
Communications Interfaces
PAGEREF _Toc441230990 \h 3
4.
System Features
PAGEREF _Toc441230991 \h 4
4.1
System Feature 1
PAGEREF _Toc441230992 \h 4
4.2
System Feature 2 (and so on)
PAGEREF _Toc441230993 \h 4
5.
Other Nonfunctional Requirements
PAGEREF _Toc441230994 \h 4
5.1
Performance Requirements
PAGEREF _Toc441230995 \h 4
5.2
Safety Requirements
PAGEREF _Toc441230996 \h 5
5.3
Security Requirements
PAGEREF _Toc441230997 \h 5
5.4
Software Quality Attributes
PAGEREF _Toc441230998 \h 5
5.5
Business Rules
PAGEREF _Toc441230999 \h 5
6.
Other Requirements
PAGEREF _Toc441231000 \h 5
Appendix A: Glossary
PAGEREF _Toc441231001 \h 5
Appendix B: Analysis Models
PAGEREF _Toc441231002 \h 5
Appendix C: To Be Determined List
PAGEREF _Toc441231003 \h 6
Revision History
Name
Date
Reason For Changes
Version
Introduction
Purpose
<Identify the product whose software requirements are specified in this document, including the revision or release number. Describe the scope of the product that is covered by this SRS, particularly if this SRS describes only part of the system or a single subsystem.>
Document Conventions
<Describe any standards or typographical conventions that were followed when writing this SRS, such as fonts or highlighting that have special significance. For example, state whether priorities for higher-level requirements are assumed to be inherited by detailed requirements, or whether every requirement statement is to have its own priority.>
Intended Audience and Reading Suggestions
<Describe the different types of reader that the document is intended for, such as developers, project managers, marketing staff, users, testers, and documentation writers. Describ.
According to an article published in Forbes in 2010, the 10 essent.docxnettletondevon
According to an article published in Forbes in 2010, the 10 essentials of an effective website includes the following: company/product easily identifiable, front and center contact information, fast search bar, speed; detailed, well-organized content; product qualities highlighted, differentiated benefits presented, encourages return visit, easy to navigate, and fresh new content.
Visit two-three websites for ONE type of product (e.g., laptops, laundry detergents, beverages, athletic shoes, etc.) and analyze the layout of these sites including the 10 essential elements listed above. Respond to the following questions evaluating the overall effectiveness of the websites.
1. How does a consumer’s perception affect the influence the website has on the consumer? Include a discussion of the sensory aspects.
2. What are the stages of perception as it relates to consumer decision and buying? Relate these stages to the qualities of effective websites as identified by Forbes.
3. How does a consumer’s personality affect his or her buying decisions which inevitably shapes his or her lifestyles? Include a discussion of how a consumer’s view of him or herself also impacts buying decisions.
4. Analyze the effectiveness of the websites in reaching their respective target markets. What specific things would you recommend implementing in order to improve upon the effectiveness?
Your response should be a minimum of two pages, double-spaced. References should include your textbook plus a minimum of one additional credible reference. All sources used, including the textbook, must be referenced; paraphrased and quoted material must have accompanying citations, and cited per APA guidelines.
Title of the Project
by
Student Name
This is an Engineering project submitted to the Gannon University graduate faculty in
partial fulfillment for the degree Master of Science in Engineering.
Major Subject: Electrical Engineering
Approved:
Advising Professor in Charge of Major Work
Chairperson of Major Department
Gannon University
Erie, Pennsylvania 16541
Month, Year
Acknowledgements
The writer thanks mentors, colleagues, lists the individuals or institutions that supported the research, and gives credit to works cited in the text for which permission to reproduce has be granted. ACKNOWLEDGMENTS appears centered at the top of the page.
Abstract
Give a 60-100 word abstract/executive summary of the project here.The abstract briefly summarizes the thesis and the contents of the paper. ABSTRACT appears centered at the top of the page.
Table of Contents
51.
INTRODUCTION
1.1
Scope
6
1.2
Background
6
1.3
Summary
6
1.4
Road Map to the report
6
2.
REQUIREMENTS ANALYSIS
7
2.1
System Overview
7
2.2
Application Constraints and Dependencies
7
2.3
Specific Requirements
7
2.4
Interfaces
7
2.5
Summary
8
SYSTEM DESIGN
9
3.1
Top Level Design
9
3.2
Product Flow
9
Interface
9
3.4
Description
9
3.5
Initialization
10
3.6
Interface Design
10
3.7
Functional Design
11
.
1. Functional Specification Standard
By Dino Fancellu
Published at: http://www.softwarereality.com/lifecycle/functionalspec.jsp
Introduction
In general terms, the functional specification states what the proposed system
is to do, whereas design is how the system is to be constructed to meet the
functional specification. However in writing it, some consideration of design
issues must take place, to ensure a realistic system is specified.
The functional specification should be clear, consistent, precise and
unambiguous. The user requirement may mean that the user interface should
be included in this document for some projects, whereas for others this will be
done at the design stage either within a document or developed via a
prototype.
It is important that there is a draft functional specification before the design
stage on any project is started and that the functional specification is agreed
and issued normally within a week of the final quality review. There must be a
milestone on the project plan for the issue of the functional specification. The
functional specification must be kept up-to-date, as this is the communication
with the world outside the development staff.
The following should be used as a standard for a functional specification with
some mandatory sections. The layout itself is at the discretion of the author
except for Chapter 1. The document should have a standard front page,
document authorisation page containing the title, issue, author and quality
controller and contents page. Use diagrams where appropriate.
Do not be afraid of examples! Use them copiously throughout, as a brief,
concrete example often illustrates a point much more succinctly than a
normative explanation. Also remember to keep the examples interesting, as
this is a useful way of keeping the reader’s interest – this is just as important
in a functional specification as in any other type of document.
1. Introduction
An introductory sentence or two about the project as this is probably the first
document written on the project.
1.1. Summary
A few sentences summarising the project: what it is, who it is for (customer or
internal), is it a bespoke project, a product, a demo.
2. 1.2. Requirements
This section should state the requirements the functional specification is
attempting to fulfil. This may be an understanding of a customer’s requirement
or a statement given as an internal starting point, e.g. produce a
comprehensive mail tool in minimum time. Normally requirements are by their
nature unstructured with high and low level statements intermingled. This
section should refer to a separate requirements document if it exists. If there
is anything else clarifying the requirement such as faxes these should also be
referred to and probably a copy put into an Appendix.
1.3. Numbers
This section should detail the number of users expected to use the system,
how often, expected number of transactions (per minute/hour/day), peak
usage times etc.
The question that should be asked of project stakeholders up-front is: "What
numbers are we looking at?"
Capacity/response time needs have to be outlined so that we don't come up
with a slow/tiny system, or don't totally over-do it and come up with a n-tier
EJB solution costing £500k, when the system will only ever have 20
simultaneous users.
Such information will make a big difference to the architecture, i.e. the
eventual design specification. This is why it is vital to establish these figures
early in the project.
These figures are such an overarching issue that they do not belong in any
one section. In fact the issue is expanded upon in several sections, such as
User Community, Performance and Expandability.
1.4. Existing System
This section should include an explanation of the system we are replacing,
even if it’s an old manual system.
What problems does the current system have? Which of these problems do
we solve?
What useful functions of the current system will we not provide (Constraints)?
Depending on the depth of analysis required, this section may also describe
the root causes of each problem. “Root cause” analysis is a systematic way of
uncovering the underlying cause of an identified problem:
“It’s amazing how much people do know about the problem behind the
problem; it’s just that no-one – by which we usually mean management
– had taken the time to ask them before. So, ask them and then ask
them again.”
Source: Managing Software Requirements: A Unified Approach by Dean Leffingwell,
Don Widrig – Chapter 4, “The Five Steps in Problem Analysis”
3. 1.5. Terminology
This section should contain all words or phrases having a special meaning for
this project with a clear, concise, unambiguous statement on their meaning.
1.6. References
List any document references with numbers, remembering to include issue
numbers and/or dates so that the actual version is identified and refer to them
as ref[n] in the rest of the document.
2. Functional Description
The rest of the document may be divided into individual sections or chapters
depending on the size and complexity of the system. Avoid forward
references as the flow of the document is lost; consider re-ordering of the
document in such circumstances.
Whereas requirements tend to be unstructured, the functions provided to fulfil
the requirements must be structured. All statements as to functionality, should
be written clearly using consistent terminology such that a test could be
written to ensure the final system, performs as described and also that a
design should fall naturally with no interpretation being necessary. It should
be possible to draw up a table of functions within full system and product tests
and incorporate a test for each function. To this end all functional statements
should be numbered.
It may be that basic functionality could be identified such that some items are
mandatory whereas some are highly desirable which should be clear from the
requirements. If this is so, then identify these in this specification.
The functions should be grouped where possible under sub-headings to make
an easily readable and understandable system.
All the following underlined headings must be included somewhere in the
document, not necessarily in the order given here. If it is not relevant or we
are not addressing it for this system, then say so.
Use Cases
Most likely these will be kept in a separate document or CASE tool,
referenced from the functional specification. Development of the use cases
and functional specification should happen in parallel, where information from
one feeds the other incrementally.
Always avoid repetition. The amount of detail in the rest of the functional
specification will depend on the number of use cases that have been written.
Although important, use cases do not capture all functional requirements: this
is why we need an encompassing functional specification. The availability of a
separate document also discourages use case authors from putting too much
detail in the use case (e.g. functional requirements instead of usage scenario
4. text) or the wrong detail (e.g. boundary conditions), which are both common
mistakes.
(Note this is a similar approach to the Unified Process “Supplementary Spec”
which captures additional detail that should be kept separate from the use
case).
Where the functional specification references a use case, always use the
unique use case name (e.g. “Perform Order Entry”). Depending on the size of
the system being modelled, you might also need to include the package
name.
Similarly, if the use case references an item in the functional spec, always use
the section and number of the functional item (e.g. “User Community, item
1.2.3.4”). If possible (given the constraints of the word processor or CASE tool
being used) provide a hyperlink that takes the reader directly to the
referenced item.
User Community
Identification of who the system is aimed at. There may be more than one
group of people and each group may have slightly different requirements. Are
we providing different functions to fulfil these or not?
These groups of people are normally identified as use case roles (i.e. actors),
and the functions assigned to each role as individual use cases. Where this
information does not fit into the use case model, it should be captured in the
main functional specification instead.
Administration Functions
How will the system be administered? Are there separate functions for an
administrator? Is there any security built in to stop others using administrative
functions? Passwords?
Error Handling
How errors should be handled should be stated. Identify the different types
and reasons for the classification.
Security
Security considerations are an important part of any project. This section
should detail possibilities of abuse of the system.
Along with error handling, the specification has to handle “the negative path”.
There is no point in having a system that does lots of good things if it also
does lots of bad things.
Help
What type of help is to be provided?
5. Printing
Ensure any printing to be provided is stated.
Interfaces
User
This could be a chapter in its own right if it is a full definition. If it is deferred to
the design specification stage, this should be stated.
Software
We may be interfacing to existing software. This should be stated, e.g.
toolkits, back ends of existing packages. State versions. Do interface
documents exist?
Boundary Conditions
It should be clear what are the extremes to be taken into consideration. These
items may have come up. This will vary with different systems but it could be
items such as number of users, size of forms, number of forms.
Constraints
All other constraints not specified under particular headings. For example:
economic, political, technical, system, environmental, scheduling constraints.
Platforms
We should list which platforms we will be supporting. Name a reference
platform or platforms plus appropriate operating system versions.
Internationalisation
Is this to be included in the product now or in the future?
Performance
Capacity
Response times
Portability
Although we may only be supporting one platform initially, we almost certainly
will want to be able to port developments to other platforms. This should be
stated here.
Expandability
State the likely expansion requirements. Some of the items may have been
considered earlier in the document. These should be referred to from this
section and any additional items put in.
Customisation
Are we allowing the user to customise the system? If so, what are we going to
6. provide?
Support & Maintenance
Are any functions to be included to make maintenance and support easier,
e.g. internal monitoring of traffic flows.
Configuration Management
How are we proposing to manage the various software versions?
Documentation
List the documents that will be produced. This could refer to the project plan if
that exists and contains such a list, otherwise it should be stated here.