Upload
jyotsna
View
104
Download
0
Embed Size (px)
Citation preview
__________________________________________________________________
1.0 DOCUMENT CONTROL
Author / Owner Reviewer Authoriser
Signature
Name Purnima Menon Shrikant Brahme Raj Dhillon
Designation SEPG Head – SEPG Management Representative
2.0 INTRODUCTION
Preparing the Requirements Specification is a key software life cycle event, for all turnkey software projects executed by ZENSAR. The customer may ask ZENSAR to prepare a Requirements Specification or the customer could supply the Requirements Specification.
3.0 OBJECTIVE
The objective of this document is to provide a guideline to arrive at a Requirements Specification which is unambiguous, complete as far as possible, verifiable, modifiable, traceable and usable during the development of software or maintenance of installed turnkey software or already existing software.
4.0 SCOPE
This format applies to all Requirements Specification documents, unless otherwise a separate standard is explicitly specified by the customer.
The purpose of the projectUser problem or background of the project effortIn existing system what kind of problems faced by the user and background work done by the client.Goals of the project
It should includes what exactly wants to achieve from this system by keeping that goal in mind implementation should be done.
Technology Used:
Software and Hardware Requirements:_________________________________________________________________
__________________________________________________________________
iii) User of the productHands on users – people who operate the product and number of simultaneous usersPriorities assigned to usersUser participation – an estimate of needed involvement in the project
User classes may vary as an end-user, super user or administrator with there specific characteristics.
iv) BenefitHere, will describe the details of who is the beneficiary of this system that may be client perspective, administration point of view, end-user point of view, planner point of view or etc.v) Limitations
Limitations of the system in terms of number of transactions, batch processing, hardware configuration and etc.
vi) Critical success factorsIn order to make development successful, enlist the critical factors and taken into consideration while going through software development life cycle.
2) Architecture about flow of the systemIt would deals with what way data is to be processed and information has to be passed to the destination through bridges, routers or hub etc.
3) Project constraintsi) Mandated constraint
Solution design constraintImplementation environment of the current systemPartner or collaborative applications to be used by the productOff the shelf software used within the productAnticipated workplace environmentProject duration budgetFinancial budget for the project
ii) Relevant Facts, Assumptions and DependenciesFactors that have an effect on the product but are not mandated requirements
iii) ConstraintsAssumption the team is making about the project
46.7 System Objectives
The system objectives should cover the business objectives and the quality objectives, as far as possible in full detail and in measurable terms.
This process tries to ensure that all aspects necessary to satisfy the customer's need regarding the deliverable software and associated accessories are defined and/or mentioned. All such objectives could be addressed in this section.
As a guideline to write these objectives, the following points must be considered:
a) Functional requirements:
_________________________________________________________________
__________________________________________________________________
i) Functionality - A set of attributes characterising what the software does to fulfil the user's functional needs. Each functional requirement should be stated in terms of input and output and the needed transformation, as seen by the user.
ii) Interoperability - Ability to interact with specified systems as mentioned in the section System Interfaces later in this standard.
iii) Compliance - Adherence to application related standards, conventions or regulations.
Data requirements Volumes of data, normalization, etc
5b)Reliability requirements:
i) Fault tolerance - Ability to maintain a specified level of performance in case of software faults or of infringement of its specified interface. Fail safe capability.
ii) Recoverability - Capability to re-establish its level of performance and recover the data directly affected in case of a failure.
iii) Load / Stress – Requirements to evaluate a system or component at or beyond the limits of its specified boundaries.
c) Usability
i) Understandability - User's effort for recognising the logical concept and its applicability.
ii) Learnability - User's effort for learning the application.iii) Operability - User's effort for operation of the application and
operational control.d) Efficiency:
i) Time behaviour - Response and processing time and throughput rates.ii) Resource behaviour - Amount of resources used.
e) Performance
i) Performance in terms of response time, number of simultaneous users, administration efforts etc
Non-Functional RequirementsLook and feel requirementsLook and feel of screens and sub screensUser interfaces
o GUI screen layout / Screen TransitionsIt should consist all types of screen layouts.o GUI report layoutIt should consist all types of report layouts
Interface appearanceHow it looks like.
Usability and Humanity Requirements
_________________________________________________________________
__________________________________________________________________
i) Understandability - User's effort for recognising the logical concept and its applicability.
ii) Learnability - User's effort for learning the application.iii) Operability - User's effort for operation of the application and
operational control.
Ease of usePersonalization and Internationalization requirementsEase of learningAccessibility requirements
Performance requirementsResponse time requirementSpeed and latency requirementsSafety critical requirementsPrecision requirementsReliability and availability requirements
i) Fault tolerance - Ability to maintain a specified level of performance in case of software faults or of infringement of its specified interface. Fail safe capability.
iv) Recoverability - Capability to re-establish its level of performance and recover the data directly affected in case of a failure.
v) Load / Stress – Requirements to evaluate a system or component at or beyond the limits of its specified boundaries.
Robustness requirementsCapacity requirementsScalability or extensibility requirements
Operational requirementsExpected physical environment
What kind of hardware configuration to be used for development and testing and which operating system and software to be used for development.
Expected technological environmentPartner applicationsProductization requirements
Maintainability and support requirementsMaintenance requirementsSpecial conditions for maintenanceSupportabilityAdaptability requirements
Security requirementsAccess requirementsIntegrity requirementsPrivacy requirementsAudit requirementsImmunity requirements (temporary or permanent security requirement)
New problemsNew problems caused by installing the product in the current environmentAffects on the installed system
_________________________________________________________________
__________________________________________________________________
Adverse effects on existing usersLimitations of the anticipated implementation environmentOther problems
TasksSteps to be taken to deliver the productDevelopment phases
Risks Pertaining to market risk, credit risk and operational risk.
Costs
Database Design:
6.2 Glossary
The Glossary of Terms should contain a list of all the acronyms used in the Requirements Specification. Barring standard terminology already accepted between ZENSAR and the customer, all new or ambiguous terminology must be explained sufficiently so as to prevent multiple interpretations, provide only a unique interpretation and ensure that there are no semantic or syntactic variations across the document. If possible, synonyms, simple phrases, analogies or references to related standard terminology, which is widely accepted, should be used.
_________________________________________________________________