Document Sample
Assignment Powered By Docstoc
					Assignment in Software Engineering

       Helen Grace A. Fernandez

           January 11, 2011

 0.1   Planning of Software Project . . . . . . . .   .   .   .   .   .   .   .   .   .   .   . 2
       0.1.1 Step 1: Project Goals . . . . . .        .   .   .   .   .   .   .   .   .   .   . 2
       0.1.2 Step 2: Project Deliverables . .         .   .   .   .   .   .   .   .   .   .   . 3
       0.1.3 Step 3: Project Schedule . . . .         .   .   .   .   .   .   .   .   .   .   . 3
       0.1.4 Step 4: Supporting Plans . . .           .   .   .   .   .   .   .   .   .   .   . 4
 0.2   Effort Estimation . . . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   . 5
 0.3   Software Requirements Specifications (SrS)      .   .   .   .   .   .   .   .   .   .   . 7
 0.4   Sample of Srs Format . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   . 14

0.1     Planning of Software Project
The key to a successful project is in the planning. Creating a project plan is
the first thing you should do when undertaking any kind of project.
Often project planning is ignored in favour of getting on with the work.
However, many people fail to realise the value of a project plan in saving
time, money and many problems.
This article looks at a simple, practical approach to project planning. On
completion of this guide, you should have a sound project planning approach
that you can use for future projects.

0.1.1    Step 1: Project Goals
A project is successful when the needs of the stakeholders have been met. A
stakeholder is anybody directly, or indirectly impacted by the project. As a
first step, it is important to identify the stakeholders in your project. It is
not always easy to identify the stakeholders of a project, particularly those
impacted indirectly. Examples of stakeholders are:

   • The project sponsor.

   • The customer who receives the deliverables.

   • The users of the project outputs.

   • The project manager and project team.

Once you understand who the stakeholders are, the next step is to find out
their needs. The best way to do this is by conducting stakeholder interviews.
Take time during the interviews to draw out the true needs that create real
benefits. Often stakeholders will talk about needs that aren’t relevant and
don’t deliver benefits. These can be recorded and set as a low priority.
    The next step, once you have conducted all the interviews, and have a
comprehensive list of needs is to prioritise them. From the prioritised list,
create a set of goals that can be easily measured. A technique for doing this
is to review them against the SMART principle. This way it will be easy to
know when a goal has been achieved.

    Once you have established a clear set of goals, they should be recorded in
the project plan. It can be useful to also include the needs and expectations
of your stakeholders.
    This is the most difficult part of the planning process completed. It’s
time to move on and look at the project deliverables.

0.1.2      Step 2: Project Deliverables
   Using the goals you have defined in step 1, create a list of things the
project needs to deliver in order to meet those goals. Specify when and how
each item must be delivered.
   Add the deliverables to the project plan with an estimated delivery date.
More accurate delivery dates will be established during the scheduling phase,
which is next.

0.1.3      Step 3: Project Schedule
   Create a list of tasks that need to be carried out for each deliverable
identified in step 2. For each task identify the following:

     • The amount of effort (hours or days) required to complete the task.

     • The resource who will carryout the task.

Once you have established the amount of effort for each task, you can workout
the effort required for each deliverable, and an accurate delivery date. Update
your deliverables section with the more accurate delivery dates.
   At this point in the planning, you could choose to use a software package
such as Microsoft Project to create your project schedule. Alternatively, use
one of the many free templates available. Input all of the deliverables, tasks,
durations and the resources who will complete each task.
   A common problem discovered at this point, is when a project has an
imposed delivery deadline from the sponsor that is not realistic based on
your estimates. If you discover that this is the case, you must contact the
sponsor immediately. The options you have in this situation are:

     • Renegotiate the deadline (project delay).

   • Employ additional resources (increased cost).

   • Reduce the scope of the project (less delivered).

Use the project schedule to justify pursuing one of these options.

0.1.4     Step 4: Supporting Plans
This section deals with plans you should create as part of the planning pro-
cess. These can be included directly in the plan. Human Resource Plan
    Identify by name, the individuals and organisations with a leading role in
the project. For each, describe their roles and responsibilities on the project.
    Next, describe the number and type of people needed to carryout the
project. For each resource detail start dates, estimated duration and the
method you will use for obtaining them.
    Create a single sheet containing this information.
Communications Plan
    Create a document showing who needs to be kept informed about the
project and how they will receive the information. The most common mech-
anism is a weekly or monthly progress report, describing how the project is
performing, milestones achieved and work planned for the next period.
Risk Management Plan
    Risk management is an important part of project management. Although
often overlooked, it is important to identify as many risks to your project as
possible, and be prepared if something bad happens.
    Here are some examples of common project risks:

   • Time and cost estimates too optimistic.

   • Customer review and feedback cycle too slow.

   • Unexpected budget cuts.

   • Unclear roles and responsibilities.

   • Stakeholder input is not sought, or their needs are not properly under-

   • Stakeholders changing requirements after the project has started.

   • Stakeholders adding new requirements after the project has started.

   • Poor communication resulting in misunderstandings, quality problems
     and rework.

   • Lack of resource commitment.
Risks can be tracked using a simple risk log. Add each risk you have identified
to your risk log; write down what you will do in the event it occurs, and
what you will do to prevent it from occurring. Review your risk log on a
regular basis, adding new risks as they occur during the life of the project.
Remember, when risks are ignored they don’t go away.
   Congratulations. Having followed all the steps above, you should have a
good project plan. Remember to update your plan as the project progresses,
and measure progress against the plan.
Project Planning a Step by Step Guide
By Duncan Haughey, PMP

0.2     Effort Estimation
   Effort estimation consists in predict how many hours of work
and how many workers are needed to develop a project. The effort
invested in a software project is probably one of the most impor-
tant and most analysed variables in recent years in the process of
project management. The determination of the value of this vari-
able when initiating software projects allows us to plan adequately
any forthcoming activities. As far as estimation and prediction is
concerned there is still a number of unsolved problems and errors.
To obtain good results it is essential to take into consideration any
previous projects. Estimating the effort with a high grade of re-
liability is a problem which has not yet been solved and even the
project manager has to deal with it since the beginning.

    Several methods have been used to analyse data, but the ref-
erence technique has always been the classic regression method.
Therefore, it becomes necessary to use some other techniques that
search in the space of non linear relationship. Some works in the
field have built up models (through equations) according to the
size, which is the factor that affects the cost (effort) of the project
the most [Dol00],[KT85]. The equation that relates size and effort

can be adjusted due to different environmental factors such as pro-
ductivity, tools, complexity of the product and other ones. The
equations are usually adjusted by the analyst to fit the real data.

     From this perspective, different equation patterns have come
out [Dol00],[Hu97]. but none of them has produced enough evi-
dence to be considered the definitive cost function, in case there
is one. Nevertheless, the characteristic that has to be satisfied by
the estimation equation is: the model should be capable of doing
its best on estimating reliably the majority of the real values.
It hasn’t been possible until now to obtain an equation, set of equa-
tions or patterns of equations that can satisfy this premise, and
therefore there is no reference of comparison parameter. Then it
can be assumed that the equations are not a good tool to obtain
an optimum prediction.
Instances and best known solutions for those instances:

   The estimation of the effort invested in the development of soft-
ware projects can turn into a complicated problem to be solved if
the appropriate models are not available. Unfortunately, until this
moment this is the situation, since there are not the necessary
records in the software development companies. Years of investi-
gation are required in order to obtain the volumes of information
needed to carry out a prediction with a good level of reliability and
with a low error margin.

   The domains are not the most suitable, due to their size and
limited number of variables, and because of the fact that they
depend on the particular casuistry of each company. The quality
of the prediction can improve if more appropriate sets of data are
available and more deep study of the methods is performed.

   Sets of data are provided bellow. Each set shows information
about certain amount of software development projects. For each
project, there are two variables: one, (independant variable) that
refers to the size of the generated code -measured in lines of code or
function points-, and the other (dependant variable) that indicates

the effort (time) invested in the development of projects. Columns
”Size” and ”Effort” show the measure used. Column ”Projects”
shows the number of projects in the data.

0.3    Software Requirements Specifications (SrS)
What Makes a Great Software Requirements Specification?

   There are many good definitions of System and Software Re-
quirements Specifications that will provide us a good basis upon
which we can both define a great specification and help us identify
deficiencies in our past efforts. There is also a lot of great stuff on
the web about writing good specifications. The problem is not lack
of knowledge about how to create a correctly formatted specifica-
tion or even what should go into the specification. The problem is
that we don’t follow the definitions out there.

   We have to keep in mind that the goal is not to create great spec-
ifications but to create great products and great software. Can you
create a great product without a great specification? Absolutely!
You can also make your first million through the lottery but why
take your chances? Systems and software these days are so com-
plex that to embark on the design before knowing what you are
going to build is foolish and risky.

   The IEEE ( is an excellent source for definitions
of System and Software Specifications. As designers of real-time,
embedded system software, we use IEEE STD 830-1998 as the basis
for all of our Software Specifications unless specifically requested
by our clients. Essential to having a great Software Specification is
having a great System Specification. The equivalent IEEE standard
for that is IEEE STD 1233-1998. However, for most purposes in
smaller systems, the same templates can be used for both. What
are the benefits of a Great SRS?

   The IEEE 830 standard defines the benefits of a good SRS:
Establish the basis for agreement between the customers and the

suppliers on what the software product is to do. The complete
description of the functions to be performed by the software spec-
ified in the SRS will assist the potential users to determine if the
software specified meets their needs or how the software must be
modified to meet their needs. [NOTE: We use it as the basis of
our contract with our clients all the time].

   Reduce the development effort. The preparation of the SRS
forces the various concerned groups in the customers organization
to consider rigorously all of the requirements before design be-
gins and reduces later redesign, recoding, and retesting. Careful
review of the requirements in the SRS can reveal omissions, mis-
understandings, and inconsistencies early in the development cycle
when these problems are easier to correct.

   Provide a basis for estimating costs and schedules. The de-
scription of the product to be developed as given in the SRS is
a realistic basis for estimating project costs and can be used to
obtain approval for bids or price estimates. [NOTE: Again, we use
the SRS as the basis for our fixed price estimates]

   Provide a baseline for validation and verification. Organizations
can develop their validation and Verification plans much more pro-
ductively from a good SRS. As a part of the development contract,
the SRS provides a baseline against which compliance can be mea-
sured. [NOTE: We use the SRS to create the Test Plan].

   Facilitate transfer.The SRS makes it easier to transfer the soft-
ware product to new users or new machines. Customers thus find it
easier to transfer the software to other parts of their organization,
and suppliers find it easier to transfer it to new customers.

   Serve as a basis for enhancement. Because the SRS discusses the
product but not the project that developed it, the SRS serves as a
basis for later enhancement of the finished product. The SRS may
need to be altered, but it does provide a foundation for continued
production evaluation. [NOTE: This is often a major pitfall when

the SRS is not continually updated with changes]
What should the SRS address? .
Again from the IEEE standard: The basic issues that the SRS writer(s) shall
address are the following:

  1. Functionality. What is the software supposed to do?

  2. External interfaces. How does the software interact with people, the
     systems hardware, other hardware, and other software?

  3. Performance. What is the speed, availability, response time, recovery
     time of various software functions, etc.?

  4. Attributes. What are the portability, correctness, maintainability, se-
     curity, etc. considerations?

  5. Design constraints imposed on an implementation. Are there any re-
     quired standards in effect, implementation language, policies for database
     integrity, resource limits, operating environment(s) etc.?

   What are the characteristics of a great SRS? Again from the IEEE stan-
dard: An SRS should be

   • Correct

   • Unambiguous

   • Complete

   • Consistent

   • Ranked for importance and/or stability

   • Verifiable

   • Modifiable

   • Traceable

Correct - This is like motherhood and apple pie. Of course you
want the specification to be correct. No one writes a specification
that they know is incorrect. We like to say - ”Correct and Ever
Correcting.” The discipline is keeping the specification up to date
when you find things that are not correct. Unambiguous - An SRS
is unambiguous if, and only if, every requirement stated therein has
only one interpretation. Again, easier said than done. Spending
time on this area prior to releasing the SRS can be a waste of time.
But as you find ambiguities - fix them.
Complete - A simple judge of this is that is should be all that is
needed by the software designers to create the software.
Consistent - The SRS should be consistent within itself and con-
sistent to its reference documents. If you call an input ”Start and
Stop” in one place, don’t call it ”Start/Stop” in another. Ranked
for Importance - Very often a new system has requirements that
are really marketing wish lists. Some may not be achievable. It is
useful provide this information in the SRS.
Verifiable - Don’t put in requirements like - ”It should provide the
user a fast response.” Another of my favorites is - ”The system
should never crash.” Instead, provide a quantitative requirement
like: ”Every key stroke should provide a user response within 100
Modifiable - Having the same requirement in more than one place
may not be wrong - but tends to make the document not main-
Traceable - Often, this is not important in a non-politicized envi-
ronment. However, in most organizations, it is sometimes useful to
connect the requirements in the SRS to a higher level document.
Why do we need this requirement?
What is the difference between a System Specification and a Soft-
ware Specification?
Very often we find that companies do not understand the difference between
a System specification and a Software Specification. Important issues are not
defined up front and Mechanical, Electronic and Software designers do not

really know what their requirements are. The following is a high level list of
requirements that should be addressed in a System Specification:

   • Define the functions of the system

   • Define the Hardware / Software Functional Partitioning

   • Define the Performance Specification

   • Define the Hardware / Software Performance Partitioning

   • Define Safety Requirements

   • Define the User Interface (A good users manual is often an overlooked
     part of the System specification. Many of our customers havent even
     considered that this is the right time to write the users manual.)

   • Provide Installation Drawings/Instructions.

   • Provide Interface Control Drawings (ICDs, External I/O)

    One job of the System specification is to define the full func-
tionality of the system. In many systems we work on, some func-
tionality is performed in hardware and some in software. It is the
job of the System specification to define the full functionality and
like the performance requirements, to set in motion the trade-offs
and preliminary design studies to allocate these functions to the
different disciplines (mechanical, electrical, software).

   Another function of the System specification is to specify per-
formance. For example, if the System is required to move a mech-
anism to a particular position accurate to a repeatability of 1
millimeter, that is a Systems requirement. Some portion of that
repeatability specification will belong to the mechanical hardware,
some to the servo amplifier and electronics and some to the soft-
ware. It is the job of the System specification to provide that
requirement and to set in motion the partitioning between me-
chanical hardware, electronics, and software. Very often the Sys-
tem specification will leave this partitioning until later when you
learn more about the system and certain factors are traded off (For

example, if we do this in software we would need to run the proces-
sor clock at 40 mHz. However, if we did this function in hardware,
we could run the processor clock at 12 mHz). [This implies that
a certain level of research or even prototyping and benchmarking
needs to be done to create a System spec. I think it is useful to
say that explicitly.]

    However, for all practical purposes, most of the systems we are
involved with in small to medium size companies, combine the soft-
ware and the systems documents. This is done primarily because
most of the complexity is in the software. When the hardware is
used to meet a functional requirement, it often is something that
the software wants to be well documented. Very often, the software
is called upon to meet the system requirement with the hardware
you have. Very often, there is not a systems department to drive
the project and the software engineers become the systems engi-
neers. For small projects, this is workable even if not ideal. In this
case, the specification should make clear which requirements are
software, which are hardware, and which are mechanical.
What is the difference between a design requirement and software
In short, the SRS should not include any design requirements. However, this
is a difficult discipline. For example, because of the partitioning and the par-
ticular RTOS you are using, and the particular hardware you are using, you
may require that no task use more than 1 ms of processing prior to releasing
control back to the RTOS. Although that may be a true requirement and it
involves software and should be tested it is truly a design requirement and
should be included in the Software Design Document or in the Source code.
Consider the target audience for each specification to identify what goes into
what documents. Marketing/Product Management
Creates a product specification and gives it to Systems. It should define
everything Systems needs to specify the product Systems
Creates a System Specification and gives it to Systems/Software and Me-
chanical and Electrical Design. Systems/Software
Creates a Software Specification and gives it to Software. It should define
everything Software needs to develop the software.
Thus, the SRS should define everything explicitly or (preferably) by reference

that software needs to develop the software. References should include the
version number of the target document. Also, consider using master docu-
ment tools which allow you to include other documents and easily access the
full requirements.
    Is this do-able? Wont we miss our deadlines if we take the time
to do this?
This is a great question. There is no question that there is balance in this
process. We have seen companies and individuals go overboard on docu-
menting software that doesnt need to be documented, such as a temporary
utility. We have also seen customers kill good products by spending too much
time specifying it. However, the bigger problem is at the other end of the
spectrum. We have found that taking the time up front pays dividends down
stream. If you dont have time to specify it up front, you probably dont have
the time to do the project. Here are some of our guidelines:

   • Spend time specifying and documenting well software that you plan to

   • Keep documentation to a minimum when the software will only be used
     for a short time or has a limited number of users.

   • Have separate individuals write the specifications (not the individual
     who will write the code).

   • The person to write the specification should have good communication

   • Pretty diagrams can help but often tables and charts are easier to
     maintain and can communicate the same requirements.

   • Take your time with complicated requirements. Vagueness in those
     areas will come back to bite you later.

   • Conversely, watch out for over-documenting those functions that are
     well understood by many people but for which you can create some
     great requirements.

   • Keep the SRS up to date as you make changes.

   • Approximately 20-25

   • Keep 5

   • Test the requirements document by using it as the basis for writing the
     test plan.

0.4     Sample of Srs Format
Software Requirements Specification
Version 1.0 approved
Prepared by (author)
(date created)
Table of Contents
Table of Contents ii
Revision History ii
1. Introduction 1
1.1 Purpose 1
1.2 Document Conventions 1
1.3 Intended Audience and Reading Suggestions 1
1.4 Project Scope 1
1.5 References 1
2. Overall Description 2
2.1 Product Perspective 2
2.2 Product Features 2
2.3 User Classes and Characteristics 2
2.4 Operating Environment 2
2.5 Design and Implementation Constraints 2
2.6 User Documentation 2
2.7 Assumptions and Dependencies 3
3. System Features 3
3.1 System Feature 1 3
3.2 System Feature 2 (and so on) 4
4. External Interface Requirements 4
4.1 User Interfaces 4

4.2 Hardware Interfaces 4
4.3 Software Interfaces 4
4.4 Communications Interfaces 4
5. Other Nonfunctional Requirements 5
5.1 Performance Requirements 5
5.2 Safety Requirements 5
5.3 Security Requirements 5
5.4 Software Quality Attributes 5
6. Other Requirements 5
Appendix A: Glossary 5
Appendix B: Analysis Models 6
Appendix C: Issues List 6
Revision History
Name Date Reason For Changes Version
1. Introduction
1.1 Purpose
(Identify the product whose software requirements are specified in this doc-
ument, 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.)
1.2 Document Conventions
(Describe any standards or typographical conventions that were followed
when writing this SRS, such as fonts or highlighting that have special sig-
nificance. For example, state whether priorities for higher-level requirements
are assumed to be inherited by detailed requirements, or whether every re-
quirement statement is to have its own priority.)
1.3 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. Describe what the rest of this SRS contains and how
it is organized. Suggest a sequence for reading the document, beginning with
the overview sections and proceeding through the sections that are most per-
tinent to each reader type.)
1.4 Project Scope
(Provide a short description of the software being specified and its purpose,
including relevant benefits, objectives, and goals. Relate the software to cor-
porate goals or business strategies. If a separate vision and scope document
is available, refer to it rather than duplicating its contents here. An SRS

that specifies the next release of an evolving product should contain its own
scope statement as a subset of the long-term strategic product vision.)
1.5 References
(List any other documents or Web addresses to which this SRS refers. These
may include user interface style guides, contracts, standards, system require-
ments specifications, use case documents, or a vision and scope document.
Provide enough information so that the reader could access a copy of each
reference, including title, author, version number, date, and source or loca-
2. Overall Description
2.1 Product Perspective
(Describe the context and origin of the product being specified in this SRS.
For example, state whether this product is a follow-on member of a product
family, a replacement for certain existing systems, or a new, self-contained
product. If the SRS defines a component of a larger system, relate the re-
quirements of the larger system to the functionality of this software and
identify interfaces between the two. A simple diagram that shows the major
components of the overall system, subsystem interconnections, and external
interfaces can be helpful.)
2.2 Product Features
(Summarize the major features the product contains or the significant func-
tions that it performs or lets the user perform. Details will be provided in
Section 3, so only a high level summary is needed here. Organize the func-
tions to make them understandable to any reader of the SRS. A picture of
the major groups of related requirements and how they relate, such as a top
level data flow diagram or a class diagram, is often effective.)
2.3 User Classes and Characteristics
(Identify the various user classes that you anticipate will use this product.
User classes may be differentiated based on frequency of use, subset of prod-
uct functions used, technical expertise, security or privilege levels, educa-
tional level, or experience. Describe the pertinent characteristics of each
user class. Certain requirements may pertain only to certain user classes.
Distinguish the favored user classes from those who are less important to
2.4 Operating Environment
(Describe the environment in which the software will operate, including the
hardware platform, operating system and versions, and any other software
components or applications with which it must peacefully coexist.)

2.5 Design and Implementation Constraints
(Describe any items or issues that will limit the options available to the de-
velopers. These might include: corporate or regulatory policies; hardware
limitations (timing requirements, memory requirements); interfaces to other
applications; specific technologies, tools, and databases to be used; parallel
operations; language requirements; communications protocols; security con-
siderations; design conventions or programming standards (for example, if
the customers organization will be responsible for maintaining the delivered
2.6 User Documentation
(List the user documentation components (such as user manuals, on-line help,
and tutorials) that will be delivered along with the software. Identify any
known user documentation delivery formats or standards.)
2.7 Assumptions and Dependencies
(List any assumed factors (as opposed to known facts) that could affect the
requirements stated in the SRS. These could include third-party or com-
mercial components that you plan to use, issues around the development or
operating environment, or constraints. The project could be affected if these
assumptions are incorrect, are not shared, or change. Also identify any de-
pendencies the project has on external factors, such as software components
that you intend to reuse from another project, unless they are already doc-
umented elsewhere (for example, in the vision and scope document or the
project plan))
3. System Features
(This template illustrates organizing the functional requirements for the
product by system features, the major services provided by the product.
You may prefer to organize this section by use case, mode of operation, user
class, object class, functional hierarchy, or combinations of these, whatever
makes the most logical sense for your product.)
3.1 System Feature 1
(Dont really say System Feature 1. State the feature name in just a few
3.1.1 Description and Priority
(Provide a short description of the feature and indicate whether it is of High,
Medium, or Low priority. You could also include specific priority component
ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale
from a low of 1 to a high of 9).)
3.1.2 Stimulus/Response Sequences

(List the sequences of user actions and system responses that stimulate the
behavior defined for this feature. These will correspond to the dialog ele-
ments associated with use cases.)
3.1.3 Functional Requirements
(Itemize the detailed functional requirements associated with this feature.
These are the software capabilities that must be present in order for the user
to carry out the services provided by the feature, or to execute the use case.
Include how the product should respond to anticipated error conditions or
invalid inputs. Requirements should be concise, complete, unambiguous, ver-
ifiable, and necessary. Use TBD as a placeholder to indicate when necessary
information is not yet available.))
    (Each requirement should be uniquely identified with a sequence number
or a meaningful tag of some kind.)
3.2 System Feature 2 (and so on)
4. External Interface Requirements
4.1 User Interfaces ¡Describe the logical characteristics of each interface be-
tween the software product and the users. This may include sample screen
images, any GUI standards or product family style guides that are to be fol-
lowed, screen layout constraints, standard buttons and functions (e.g., help)
that will appear on every screen, keyboard shortcuts, error message display
standards, and so on. Define the software components for which a user in-
terface is needed. Details of the user interface design should be documented
in a separate user interface specification.¿
4.2 Hardware Interfaces ¡Describe the logical and physical characteristics of
each interface between the software product and the hardware components
of the system. This may include the supported device types, the nature of
the data and control interactions between the software and the hardware,
and communication protocols to be used.¿
4.3 Software Interfaces ¡Describe the connections between this product and
other specific software components (name and version), including databases,
operating systems, tools, libraries, and integrated commercial components.
Identify the data items or messages coming into the system and going out and
describe the purpose of each. Describe the services needed and the nature
of communications. Refer to documents that describe detailed application
programming interface protocols. Identify data that will be shared across
software components. If the data sharing mechanism must be implemented

in a specific way (for example, use of a global data area in a multitasking
operating system), specify this as an implementation constraint.¿
4.4 Communications Interfaces
(Describe the requirements associated with any communications functions
required by this product, including e-mail, web browser, network server com-
munications protocols, electronic forms, and so on. Define any pertinent mes-
sage formatting. Identify any communication standards that will be used,
such as FTP or HTTP. Specify any communication security or encryption
issues, data transfer rates, and synchronization mechanisms.)
5. Other Nonfunctional Requirements
5.1 Performance Requirements
(If there are performance requirements for the product under various circum-
stances, state them here and explain their rationale, to help the developers
understand the intent and make suitable design choices. Specify the timing
relationships for real time systems. Make such requirements as specific as
possible. You may need to state performance requirements for individual
functional requirements or features.)
5.2 Safety Requirements
(Specify those requirements that are concerned with possible loss, damage,
or harm that could result from the use of the product. Define any safeguards
or actions that must be taken, as well as actions that must be prevented.
Refer to any external policies or regulations that state safety issues that af-
fect the products design or use. Define any safety certifications that must be
5.3 Security Requirements
(Specify any requirements regarding security or privacy issues surrounding
use of the product or protection of the data used or created by the product.
Define any user identity authentication requirements. Refer to any external
policies or regulations containing security issues that affect the product. De-
fine any security or privacy certifications that must be satisfied.)
5.4 Software Quality Attributes
(Specify any additional quality characteristics for the product that will be
important to either the customers or the developers. Some to consider are:
adaptability, availability, correctness, flexibility, interoperability, maintain-
ability, portability, reliability, reusability, robustness, testability, and usabil-
ity. Write these to be specific, quantitative, and verifiable when possible. At
the least, clarify the relative preferences for various attributes, such as ease
of use over ease of learning.)

6. Other Requirements
(Define any other requirements not covered elsewhere in the SRS. This might
include database requirements, internationalization requirements, legal re-
quirements, reuse objectives for the project, and so on. Add any new sections
that are pertinent to the project.) Appendix A: Glossary
(Define all the terms necessary to properly interpret the SRS, including
acronyms and abbreviations. You may wish to build a separate glossary that
spans multiple projects or the entire organization, and just include terms
specific to a single project in each SRS.) Appendix B: Analysis Models
(Optionally, include any pertinent analysis models, such as data flow dia-
grams, class diagrams, state-transition diagrams, or entity-relationship dia-
grams.) Appendix C: Issues List
( This is a dynamic list of the open requirements issues that remain to be
resolved, including TBDs, pending decisions, information that is needed,
conflicts awaiting resolution, and the like.)


Shared By:
Description: Assignment in Software Engineering