• Components Of Srs In Software Engineering

According to IEEE Std 830 SRS template, Software Requirement Specification (SRS) must have following 6 major components: Functional requirements, Performance requirements, Design Constraints, External interface requirements (user/software/hardware interface), Attributes (security, testability, maintainability etc.).

• Technical writing guidance for technical writers and technical communicators on creating software requirements specifications (SRS).
• Dec 15, 2001. This is the Software Requirements Specification (SRS) for the 'Space Fractions' project. The purpose of. The details of the project's requirements, interface, design issues, and components. 1.2 Scope of. Schach, Stephen R. Object-Oriented and Classical Software Engineering, Fifth Edition.

In the Wikipedia link for SRS, in the 'Product Perspective' section, there is a mention of the term 'System Interfaces'. I am not clear as to what exactly that means. I have looked at a few other SRS samples available online but am not able to piece together an unambiguous definition from the examples. Could someone elaborate on what 'System Interfaces' refer to?

closed as too broad by TylerH, Kara, Claies, rene, Display Name is missingJan 30 '17 at 21:40

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers

The IEEE 830-1998 standard defines 'Hardware Interfaces' as

'the logical characteristics of each interface between the software product and the hardware components of the system'

Similarly, it defines 'User Interfaces' as

'the logical characteristics of each interface between the software product and its users'.

So, a little reasoning tells us that the 'System Interface' should have been defined as

'the logical characteristics of each interface between the software product and the bigger system'.

That means, 'system interfaces' are not the bigger system's interfaces with the outside world, but the internal interfaces between the software and everything else within the bigger system, which includes user interfaces, hardware interfaces and software interfaces.

Components Of Srs In Software Engineering

Ironically, the 830-1998 is written in a so inconsistent fashion that the recommended section hierarchy is:

where 2.1.1 should really be the parent section of 2.1.2 - 2.1.4.

So they gave some vague definitions of the 'system interfaces' section:

This should list each system interface and identify the functionality of the software to accomplish the system requirement and the interface description to match the system.

Whoever wrote this, please try get a B from the 12th grade English composition class!

Anyway, as a non-native speaker, my understanding of IEEE's version of the 'System Interface' is that:

1. Software may be an independent product made for general use (e.g. commercial software, video games, etc.), or it may be a part of a bigger system which contains both software and hardware. For example, a car is a system and the embedded computer software is only a part of the system. Another example is the software in a hospital CT scanner is also a part of the system (the machine).

2. Assuming the system requirement is defined before the software requirement (i.e. top-down approach), think about

a) what functionality your software must have in order to meet the system requirement? (can't forget the bigger picture)

For example, if a automatic driving car system requirement is that 'the car shall detect sudden slow downs of the vehicles in front of the car within 0.1 seconds', then you may need to write a non-functional requirement for your software system such as 'after the software receives the 'sudden slow down' signal from the front sensor, it shall process the signal and make decisions. If it is a confirmed real scenario (not a false alarm) then the software shall send 'hit break' signal to the break system. The decision making and signal sending process shall take no longer than 0.05 seconds.

b) what are the interfaces between your software and everything else within the bigger system?

E.g. your car computer software shall have the following interface with the front sensor:

Such interfaces shall be clearly defined.

If you software is not part of a bigger system, or if it is designed to be a generic software to be run in general systems (e.g. MS Windows applications), then there is little need for specifying the 'System Interfaces' section.

System interfaces include the following: 1. User Interfaces e.g. screen format,keys 2. Hardware interfaces e.g. configuration characteristics, devices supported 3. Software interfaces e.g. an OS 4. Communication Interface - LAN

Also, you may want to include a high level view of your system in relation to all these interfaces.

Let me know if you require more details.

System interfaces in the context will mean all interfaces your system will need to perform its purpose.

Probably if your server consumes a web service response / a Queue message or a database poll, they can be counted as 3 interfaces to your system. The implementation of these interfaces will be a SOAP impl, a ACTIVEMQ broker and a database.

Not the answer you're looking for? Browse other questions tagged srs or ask your own question.

Presentation on theme: 'UNIT-II Chapter : Software Requirement Specification(SRS)'— Presentation transcript:

1 UNIT-II Chapter : Software Requirement Specification(SRS)

2 Requirements Engineering
Requirement: A function, constraint or other property that the system must provide to fill the needs of the system’s intended user(s).Engineering: implies that systematic and repeatable techniques should be usedRequirement Engineering means that requirements for a product are defined, managed and tested systematically

3 Requirements Engineering
The basic goal of requirements phase in the SDLC is to produce the Requirements Specification Document(RSD) or Software Requirement Specification (SRS) which describes the complete external behavior of the proposed software system. The process of developing this document is Requirements Engineering.

4 Requirements Engineering can be defined as
“The systematic process of documenting requirements through an interactive co-operative process of analyzing the problem, documenting the resulting observations in a variety of representation format and checking the accuracy of the understanding gained.”“ The systematic use of proven principles, techniques, tools and languages for the cost effective analysis, documentation and ongoing evolution of user needs and the specification of the external behavior of the system in order to satisfy these needs.”

5 Requirements Engineering
Input to this activity of requirements engineering are requirements which are informal and fuzzy and output is clear, well defined and consistent requirements written in formal notation RSD or SRS as shown -Informal and Fuzzy RequirementRequirementsEngineeringWell Defined Complete and Consistent Requirements

6 Requirements Engineering (RE)
It is essential that the software engineering team understand the requirements of a problem before the team tries to solve the problem.RE is software engineering actions that start with communication activity and continues into the modeling activity.RE establishes a solid base for design and construction. Without it, resulting software has a high probability of not meeting customer needs.

7 Requirements Engineering (RE)
The requirements engineering is the most crucial and most important activity in the software development life cycle because the errors introduced at this stage are the most expensive errors requiring lot of rework if detected late in the software life cycle. The SRS document produced as an output of this activity is used by successive stages of life cycle i.e. for generating design document for coding, for generating test cases in software testing and also plays a lead role in acceptance testing.

8 Requirement According to IEEE , a requirement is defined as
a condition or capability needed by a user to solve a problem or to achieve an objective.A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed document;A document representation of a condition or capability as in (i) and (ii).

9 Characteristics of a Good Requirement
Clear and Unambiguousstandard structurehas only one possible interpretationNot more than one requirement in one sentenceCorrectA requirement contributes to a real needUnderstandableA reader can easily understand the meaning of the requirementVerifiableA requirement can be testedCompleteContains all required informationConsistentDoes not conflict with other requirementsTraceableHas unique identity, cannot be broken into parts

10 Requirements readers Statements in natural language + diagrams
System’s functions, services and operational constraintsDetailed software description

11 Types of Requirements Functional requirements
Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.Non-functional requirementsconstraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.Domain requirementsRequirements that come from the application domain of the system and that reflect characteristics of that domain

12 Functional Requirements
As the name implies, functional requirements focus on the functionality of the software components that build the system.High level FR are expressed in terms of:-InputsOutputsProcessing input data in some wayIn simple words functional requirements are the services which the end users expect the final product to provide.

13 Documenting Functional Requirements
Steps:-Identify the set of services supported by the systemSpecify each of the services or functionality by identifying the input data, output data and processing done on input in order to get the output.Identify all the sub requirements for a high level requirement corresponding to the different user interactions

14 Non-functional requirements (NFRs)
NFRs are the constraints imposed on the system and deal with issues like maintainability, security, performance , reliability, probability, scalability, response time and storage requirements.Non-functional requirements are also called asQuality attributesConstraintsGoalsNon-behavioral requirementsNon-functional requirements may be more critical than functional requirements. If these are not met, the system is useless

15 Non-functional classifications
Product requirementsRequirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.Organisational requirementsRequirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.External requirementsRequirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

16 Non-functional requirement types

17 Domain requirementsDerived from the application domain and describe system characteristics and features that reflect the domainMay be new functional requirements, constraints on existing requirements or define specific computationsFor a satisfactory working of the system these are mandatory requirements to be implemented or satisfied.

18 Domain requirements problems
UnderstandabilityRequirements are expressed in the language of the application domain. This is often not understood by software engineers developing the systemImplicitnessDomain specialists understand the area so well that they do not think of making the domain requirements explicit

19 Why is Getting Good Requirements Hard?
Stakeholders don’t know what they really want.Stakeholders express requirements in their own terms.Different stakeholders may have conflicting requirements.Organisational and political factors may influence the system requirements.The requirements change during the RE process. New stakeholders may emerge and the business environment change.

20 Requirements Engineering Process
InceptionElicitationElaborationNegotiationSpecificationValidationRequirementsManagement

21 Requirements Engineering Process
Inception —Establish a basic understanding of the problem and the nature of the solution.Elicitation —Draw out the requirements from stakeholders.Elaboration (Highly structured)—Create an analysis model that represents information, functional, and behavioral aspects of the requirements.Negotiation—Agree on a deliverable system that is realistic for developers and customers.Specification—Describe the requirements formally or informally.Validation —Review the requirement specification for errors, ambiguities, omissions, and conflicts.Requirements management — Manage changing requirements.

22 Inception Inception— Ask “context-free” questions that establish …
Basic understanding of the problemThe people who want a solutionThe nature of the solution that is desired, andThe effectiveness of preliminary communication and collaboration between the customer and the developer

23 ElicitationElicitation - elicit requirements from customers, users and others.Find out from customers, users and others what the product objectives arewhat is to be donehow the product fits into business needs, andhow the product is used on a day to day basisAlso called as Requirement Analysis.

24 The Volere requirements process model suggests some additional sources for requirements.

25 Why Requirement elicitation is difficult?
Problems of scope:The boundary of the system is ill-defined.Customers/users specify unnecessary technical detail that may confuse rather than clarify objectives.Problems of understanding:Customers are not completely sure of what is needed.Customers have a poor understanding of the capabilities and limitations of the computing environment.Customers don’t have a full understanding of their problem domain.Customers have trouble communicating needs to the system engineer.Customers omit detail that is believed to be obvious.Customers specify requirements that conflict with other requirements.Customers specify requirements that are ambiguous or not able to test.Problems of volatility:Requirement change over time.

26 Tasks of Requirements Elicitation
Fact Finding – studies the organization in which the final system will be installed and defines the scope of the proposed systemCollecting Requirements – captures information from different users viewpointEvaluation – focuses on identifying inconsistencies in the requirements collectedPrioritization – prioritizes the requirements depending upon cost, user needs, ease of development etc.Consolidation – consolidates the requirements from the information gained in a way that can be analyzed further and ensures that they are consistent with the goals of the organization.

27 Requirement Eliciting Techniques
Techniques for eliciting requirement:InterviewsBrainstormingTask AnalysisForm AnalysisUser Scenarios and use case based requirement elicitationDelphi TechniqueDomain AnalysisJoint Application Design (JAD)Facilitated Application Specific Technique (FAST)Prototyping

28 1. Interviews Steps: create the questions select the interviewers
May take the form of questionnaire, open ended interviews and focus groups.Questions must be created carefully so as to extract maximum knowledge about true requirements.Interviews can be conducted on phone, personally or even over the internet.Steps:create the questionsselect the interviewersplan contactsconduct the interviewsclose the meetingdetermine where to go next

29 2. BrainstormingIs a group technique to promote creative thinking and can be used during requirements elicitation process to generate new ideas and solve problems.Session consists of a group of people who are free to say whatever comes to their mind irrespective of their relevance.People are not criticized for the ideas.Session normally last for two to three hours.

30 2. Brainstorming Session is attended by a group of 5 to 10 people.
Three types of participants with different roles:Leader: lead the brainstorming session by encouraging the participants to come up with new ideas and helping the scribe.Scribe: capture the ideas, write down each idea briefly in such a way that it is visible to all the participants present in the session. He can use tools like flip charts, overhead projectors and white boards.Participants: produce new ideas.

31 3. Task AnalysisIs a technique of decomposing the problem domain into a hierarchy of tasks and subtasks performed by the users.Eg: Donate BloodDonor approaches the blood bankStaff takes the sample of the bloodStaff checks for any infection in the blood and the blood groupIf found OK, takes the blood and stores itStaff updates the quantity of the blood group in the inventoryBlood bank issues a card to the donor for later use

32 Faculty Registration Form
4. Form AnalysisForms play an important role in any organization and contain lot of meaningful information about data objects of the domain.Faculty Registration FormName :Address :Position :Department :Date of Joining :Salary :

33 4. Form AnalysisForms are used as an input to the process of constructing ER model.NameAddressWorksinFacultyDepartmentPositionER Diagram based on previous form

34 5. User Scenario and Use case Based Requirements Elicitation
Technique for capturing requirements from users point of view.This technique is based on notion of scenario.Use case scenarios are unstructured descriptions of the user requirements.Use cases are structured descriptions of the user requirements. It is a narrative text which describes the sequence of events from users’ perspective.Use case diagrams are graphical representation to show the system at different levels of abstraction.

35 5. User Scenario and Use case Based Requirements Elicitation
Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way.Use case scenario is a story about how actor interacts with the system.Once actors are identified, then this information is used to draw Use Case Diagrams. These diagrams are supported by activity diagrams to show workflow view of activities.

36 5. User Scenario and Use case Based Requirements Elicitation
Benefits of Use case models:Easily understandable by managers, developers, users and other stakeholders of the project.Supports validation and implementation testing.Supports traceabilityEasily converted into object modelsDescribes the existing system under development accurately.

37 6. Delphi TechniqueIn delphi technique session, participants are made to write the requirements.These requirements are then exchanged among participants who give their comments to get a revised set of requirements.This process is repeated till a final consensus is reached.

38 7. Domain AnalysisThis technique focus on reuse of requirements from similar domain.It is the process of identifying, collecting, organizing and representing the relevant information in a domain.In this technique, within a domain, existing systems are studied and a generic domain model which is an abstraction of main features of applications of that domain is produced.This is just like representing the requirements at another higher level of abstraction called meta level.These requirements at meta level can then be modified to fit the problem domain.This technique will not give good results for immature or evolving domains.

39 Steps of Domain Analysis
Selection of reusable requirements.Adaptation of requirements selected in (1) for incorporating in the new model.Existing System 1Existing System 2Existing System 3META-SYSTEM REQUIREMENT SPECIFICATIONSGeneratesNew System RequirementDomain Analysis

40 8. Joint Application Design (JAD)
JAD is a registered trademark of IBM and was developed by IBM in 1970's.It is also a type of extremely effective, structured and disciplined session because it is represented by people who are well informed and knowledgeable. They are:userscustomersfunctional expertssystem expertsstakeholders of the projectIt can last upto three days and can even produce high level software models like DFDs, Use case diagrams etc. instead of documenting only ideas.

41 8. Joint Application Design (JAD)
JAD sessions are attended by:Sponsor: represents the top management and always available to resolve any issue which has come up during the sessions. He may not attend all the sessions.Facilitator: ensures that sessions are carried out smoothly and all participants attend the session with an open mind.Developers: inform the participants in the meeting about the latest tools and technology that can be used to meet the requirements.Scribe: capture and record the ideas properly.Users: explain their requirements.

42 9. Facilitated Application Specification Technique (FAST)
FAST was developed specifically for collecting requirements and is similar to brainstorming and JAD.Attended by developers & customers/end users.The meeting is controlled by facilitator and an informal agenda is published.Before starting of session, list of objects, functions and constraints is made and is presented in the session for discussion.

43 9. Facilitated Application Specification Technique (FAST)
Participants agree not to debate. After discussion some of the entries from the list is eliminated and new entries are also added to the list. This process is continued till a consensus is reached.Following activities take place additionally:Identification of external data objects.Detailed description of software functionality.Understanding the behavior of software.Establishing the interface characteristics.Describing the design constraints.

44 10. Software PrototypePrototype constructed for customer and developer assessment.In some circumstances construction of prototype is require in beginning of analysis. (To derive requirement effectively)Selecting Prototype ApproachClose ended (Throwaway Approach)Open ended (Evolutionary Approach)Close Ended – It serves as a rough demonstration of requirement. It is then discarded, and the software is engineered using a different paradigm.Open Ended - uses the prototype as the first part of an analysis activity that will be continued into design and construction. The prototype of the software is the first evolution of the finished system.

45 Approaches to prototyping

46 Evolutionary prototyping

47 Evolutionary prototyping advantages
Accelerated delivery of the systemRapid delivery and deployment are sometimes more important than functionality or long-term software maintainabilityUser engagement with the systemNot only is the system more likely to meet user requirements, they are more likely to commit to the use of the system

48 Evolutionary prototyping problems
Management problemsExisting management processes assume a waterfall model of developmentSpecialist skills are required which may not be available in all development teamsMaintenance problemsContinual change tends to corrupt system structure so long-term maintenance is expensiveContractual problemsDue to cost or time line agreed

49 Throw-away prototyping

50 Throw-away prototyping
Used to reduce requirements riskThe prototype is developed from an initial specification, delivered for experiment then discardedThe throw-away prototype should NOT be considered as a final systemSome system characteristics may have been left outThere is no specification for long-term maintenanceThe system will be poorly structured and difficult to maintain

51 ElaborationFocuses on developing a refined technical model of software functions, features, and constraints using the information obtained during inception and elicitationCreate an analysis model that identifies data, function and behavioral requirements.It is driven by the creation and refinement of user scenarios that describe how the end-user will interact with the system.Each event parsed into extracted.End result defines informational, functional and behavioral domain of the problem

52 NegotiationNegotiation - agree on a deliverable system that is realistic for developers and customersRequirements are categorized and organized into subsetsRelations among requirements identifiedRequirements reviewed for correctnessRequirements prioritized based on customer needsNegotiation about requirements, project cost and project timeline.There should be no winner and no loser in effective negotiation.

53 Specification OR Documentation
Specification – Different things to different people.It can be –Written DocumentA set of graphical models,A formal mathematical modelsCollection of usage scenario.A prototypeCombination of above.The Formality and format of a specification varies with the size and the complexity of the software to be built.For large systems, written document, language descriptions, and graphical models may be the best approach.For small systems or products, usage scenarios

54 Validation Errors in content or interpretation
Requirements Validation - formal technical review mechanism that looks forErrors in content or interpretationAreas where clarification may be requiredMissing informationInconsistencies (a major problem when large products or systems are engineered)Conflicting or unrealistic (unachievable) requirements.

55 Requirement Management
Set of activities that help project team to identify, control, and track requirements and changes as project proceedsRequirements begin with identification. Each requirement is assigned a unique identifier. Once requirement have been identified, traceability table are developed.Traceability Table:Features traceability table - shows how requirements relate to customer observable featuresSource traceability table - identifies source of each requirementDependency traceability table - indicate relations among requirementsSubsystem traceability table - requirements categorized by subsystemInterface traceability table - shows requirement relations to internal and external interfacesIt will help to track, if change in one requirement will affect different aspects of the system.

56 Software Requirement Specification (SRS) or Requirement Specification Document
SRS document is generated as output of requirement analysis.A SRS is a document which contains the complete description of software without talking much about implementation details. It is a set of precisely stated properties and constraints which final product must satisfy.Clearly and accurately describes each of the essential requirements (functions, performance, design constraints, and quality attributes) of the system / software and its external interfacesDefines the scope and boundaries of the system / software

57 Software Requirement Specification (SRS) or Requirement Specification Document
Each requirement must be described in such a way that it is feasible and objectively verifiable by a prescribed method (e.g., by inspection, demonstration, analysis, or test)Basis for contractual agreements between contractors or suppliers and customersSpecifications are intended to a diverse audienceCustomers and users for validation, contract, ...Systems (requirements) analystsDevelopers, programmers to implement the systemTesters to check that the requirements have been metProject Managers to measure and control the project

58 Components of SRS Document
Functional RequirementsNon - Functional RequirementsStatic RequirementsExecution Constraints eg. Response time, throughput timeStandards to be followedSecurity requirementsCompany PoliciesInterface with other external agents ie. persons, software or hardware

59 GOALS OF SRS DOCUMENTFeedback to customer : It is the customer’s assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems.Problem Decomposition: SRS helps to break down the problem into its component parts in an orderly fashion.Input to Design Specification : SRS contains sufficient detail in the functional system requirements so that a design solution can be devised.Product Validation Check: SRS serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.

60 Characteristics of an SRS
CorrectCompleteUnambiguousConsistentVerifiableTraceableModifiableRanked for importance and/or stabilityDesign IndependentTestabilityUnderstandable by CustomerRight level of abstraction

61 Characteristics… Correctness Completeness Unambiguous
Each requirement accurately represents some desired feature in the final systemCompletenessAll desired features/characteristics specifiedHardest to satisfyCompleteness and correctness strongly relatedUnambiguousEach requirement has exactly one meaningWithout this errors will creep inImportant as natural languages often used

62 Characteristics… Verifiability Consistent Modifiable
There must exist a cost effective way of checking if software satisfies requirementsConsistenttwo requirements don’t contradict each otherModifiableAny necessary change can be made easily while preserving completeness and consistencyRanked for importance/stabilityNeeded for prioritizing in constructionTo reduce risks due to changing requirementsRight Level of AbstractionDetails in SRS must be represented at right level of abstraction

63 Characteristics… Traceable Design Independent Testability
The origin of the requirement, and how the requirement relates to software elements can be determinedDesign IndependentProvision for multiple design alternativesTestabilityIt should be easy to generate test cases & test plans from the documentUnderstandable By CustomerAvoid using formal notations to represent requirements

64 IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications -Description
Abstract: The content and qualities of a good software requirements specification (SRS) are described and several sample SRS outlines are presented. This recommended practice is aimed at specifying requirements of software to be developed but also can be applied to assist in the selection of in-house and commercial software products. Guidelines for compliance with are also provided.Keywords: contract, customer, prototyping, software requirements specification, supplier, system requirements specifications

65 IEEE 830-1998 Standard Title of Standard
« IEEE Recommended Practice for Software Requirements Specifications »Describes the content and qualities of a good software requirements specification (SRS)Presents several sample SRS outlines

66 IEEE 830-1998 Standard – Objectives
Help software customers to accurately describe what they wish to obtainHelp software suppliers to understand exactly what the customer wantsHelp participants to:Develop a template (format and content) for the software requirements specification (SRS) in their own organizationsDevelop additional documents such as SRS quality checklists or an SRS writer’s handbook

67 IEEE 830-1998 Standard – Benefits
Establish the basis for agreement between the customers and the suppliers on what the software product is to doReduce the development effortForced to consider requirements early  reduces later redesign, recoding, retestingProvide a basis for realistic estimates of costs and schedulesProvide a basis for validation and verificationFacilitate transfer of the software product to new users or new machinesServe as a basis for enhancement requests

68 IEEE 830-1998 Standard– Considerations
Section 4 of IEEE 830 (how to produce a good SRS)Nature (goals) of SRSFunctionality, interfaces, performance, qualities, design constraintsEnvironment of the SRSWhere does it fit in the overall project hierarchyCharacteristics of a good SRSGeneralization of the characteristics of good requirements to the documentEvolution of the SRSImplies a change management processPrototypingHelps elicit software requirements and reach closure on the SRSIncluding design and project requirements in the SRSFocus on external behavior and the product, not the design and the production process (describe in a separate document)

69 IEEE 830-1998 Standard – Structure of the SRS
Section 5 of IEEE 830Contents of SRSIntroductionGeneral description of the software productSpecific requirements (detailed)Additional information such as appendixes and index, if necessary

70 IEEE 830-1998 Standard – Section 1 of SRS
TitleTable of Contents1. Introduction1.1 Purpose1.2 Scope1.3 Definitions. Acronyms, and Abbreviations1.4 References1.5 Overview2. Overall Description3. Specific Requirements4. Other RequirementsAppendicesDescribe purpose of this SRSDescribe intended audienceIdentify the software productEnumerate what the system will and will not doDescribe user classes and benefits for eachDefine the vocabulary of the SRS (may reference appendix)List all referenced documents including sources (e.g., Use Case Model and Problem Statement; Experts in the field)Describe the content of the rest of the SRSDescribe how the SRS is organized

71 IEEE 830-1998 Standard – Section 2 of SRS
Present the business case and operational concept of the systemDescribe how the proposed system fits into the business contextDescribe external interfaces: system, user, hardware, software, communicationDescribe constraints: memory, operational, site adaptationTitleTable of Contents1. Introduction2. Overall Description2.1 Product Perspective2.2 Product Functions2.3 User Characteristics2.4 Constraints2.5 Assumptions and Dependencies3. Specific Requirements4. Other RequirementsAppendicesSummarize the major functional capabilitiesInclude the Use Case Diagram and supporting narrative (identify actors and use cases)Include Data Flow Diagram if appropriateDescribe and justify technical skills and capabilities of each user classDescribe other constraints that will limit developer’s options; e.g., regulatory policies; target platform, database, network software and protocols, development standards requirementsStates assumptions about availability of certain resources that, if not satisfied, will alter system requirements and/or effect the design.

72 IEEE 830-1998 Standard – Section 3 of SRS
Specify software requirements in sufficient detail to enable designers to design a system to satisfy those requirements and testers to verify requirementsState requirements that are externally perceivable by users, operators, or externally connected systemsRequirements should include, at a minimum, a description of every input (stimulus) into the system, every output (response) from the system, and all functions performed by the system in response to an input or in support of an output(a) Requirements should have characteristics ofhigh quality requirements (b) Requirements should be cross-referenced totheir source. (c) Requirements should be uniquely identifiable (d) Requirements should be organized tomaximize readability…1. Introduction2. Overall Description3. Specific Requirements3.1 External Interfaces3.2 Functions3.3 Performance Requirements3.4 Logical Database Requirements3.5 Design Constraints3.6 Software System Quality Attributes3.7 Object Oriented Models4. Other RequirementsAppendices

73 IEEE 830-1998 Standard – Section 3 of SRS
…1. Introduction2. Overall Description3. Specific Requirements3.1 External Interfaces3.2 Functions3.3 Performance Requirements3.4 Logical Database Requirements3.5 Design Constraints3.6 Software System Quality Attributes3.7 Object Oriented Models4. Other RequirementsAppendicesDetail all inputs and outputs (complement, not duplicate, information presented in section 2)Examples: GUI screens, file formatsInclude detailed specifications of each use case, including collaboration and other diagrams useful for this purposeInclude:Types of information usedData entities and their relationshipsShould include:Standards complianceAccounting & Auditing proceduresThe main body of requirements organized in a variety of possible ways:Architecture SpecificationClass DiagramState and Collaboration DiagramsActivity Diagram (concurrent/distributed)‏

74 IEEE 830-1998 Standard – Section 4 of SRS
TitleTable of Contents1. Introduction2. Overall Description3. Specific Requirements4. Other RequirementsApportioning of requirementsDatabaseSchedule & budgetsAppendicesgive the details of requirements which are given to the third party for development.describes the details of the database which will be developed as a part of the project.describes the detailed project plan and schedule and budget estimate.

75 Requirements vs. Design
Describe what will be deliveredDescribe how it will be donePrimary goal of analysis:UNDERSTANDINGPrimary goal of design:OPTIMIZATIONThere is more than one solutionThere is only one (final) solutionCustomer interestedCustomer not interested (Most of the time) except for external