SOFTWARE SPECIFICATIONS AND REQUIREMENT ANALYSIS Software Specification A

  • Slides: 12
Download presentation

SOFTWARE SPECIFICATIONS AND REQUIREMENT ANALYSIS :

SOFTWARE SPECIFICATIONS AND REQUIREMENT ANALYSIS :

Software Specification: A document that describes what the software will do (e. g. ,

Software Specification: A document that describes what the software will do (e. g. , how it works, what the screens look like, what happens when a button is clicked, etc. ) Generally this is the first step of software programming. Software Requirement requirements specification Specification: (SRS) is a A software comprehensive description of the intended purpose and environment for software under development. The SRS fully describes what the software will do and how it will be expected to perform.

Introduction to SRS: An SRS minimizes the time and effort required by developers to

Introduction to SRS: An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes the development cost. A good SRS defines how an application will interact with system hardware, other programs and human users in a wide variety of real-world situations. Parameters such as operating speed, response time, availability, portability, maintainability, footprint, security and speed of recovery from adverse events are evaluated.

üRequirements Analysis: Part-I What is it? üThe process by which customer needs are understood

üRequirements Analysis: Part-I What is it? üThe process by which customer needs are understood and documented. ü Expresses “what” is to be built and NOT “how” it is to be built. üCustomer wants and needs; expressed in language understood by the customer. üFor the developers; may be more formal

Requirements Analysis: Part-II Why document requirements? üServes as a contract between the customer and

Requirements Analysis: Part-II Why document requirements? üServes as a contract between the customer and the developer. üServes as a source of test plans. üServes to specify project goals and plan development cycles and increments

Requirements Analysis: Part-III üIdentify the customer. ü Interview customer representatives. ü Review with customer,

Requirements Analysis: Part-III üIdentify the customer. ü Interview customer representatives. ü Review with customer, and update when necessary.

SRS’s components: üFunctional requirements: A function of a SW-system or its component. Include a

SRS’s components: üFunctional requirements: A function of a SW-system or its component. Include a set of use case that describe all of d’interactions that the users will have with d’SW üNonfunctional requirements: Requirements which impose contraints on the design or implementation (such as performance req. , quality standards, or design constraints) ü Doesn’t offer design suggestions, possible solution to tech or business issues, or any other information

The Goals of SRS: üIt provides feedback to the customer. SRS is customer's assurance

The Goals of SRS: üIt provides feedback to the customer. SRS is customer's assurance that development organization understands issues or problems to be solved and behavior necessary to address those problems and written in natural language. üIt decomposes problem into component parts. üIt serves as a product validation check. SRS serves as parent document for testing n validation strategies that will be applied to requirements for verification.

Information should an SRS include: üInterface üFunctional capabilities üPerformance level üData structures/elements üSafety üReliability

Information should an SRS include: üInterface üFunctional capabilities üPerformance level üData structures/elements üSafety üReliability üSecurity/privacy üQuality üConstraints and limitations

Characteristics of a quality SRS: Complete: SRS defines precisely all the go-life situations that

Characteristics of a quality SRS: Complete: SRS defines precisely all the go-life situations that will be encountered n the system’s capability to address them. Consistent: SRS capability functions n performance level r compatible, n the features don’t negate those capability functions. Accurate: SRS precisely defines the system’ capability in a real-world environment. Modifiable: the logical, hirarchical structure of SRS should facilitate any necessary modifiable as per need of the user. Ranked: individual requirement of SRS are hierarchically arranged according to stability, security, perceived ease/difficulty of implementation, or other parameters that help in design.

üTestable: SRS must be stated in such a manner that unambiguous assessment criteria. üTraceable:

üTestable: SRS must be stated in such a manner that unambiguous assessment criteria. üTraceable: Each requirement in SRS must be uniquely identified to a source (use case, gov reg, industry standard, etc) üUnambiguous: SRS must contain requirement statement that can be interpreted in one way only. üValid: All parties n project participants can understand, analyze, accept, or approve the SRS üVerifiable: SRS is consistent from 1 level of abstraction to another