1 / 15

Functional and Non-functional requirements

Functional and Non-functional requirements . Specification and Types. Motivation. Short and usable definition: Essential signs on the rod that lead to a successful project Formal agreement between client and provider that they have the same goal Usable representation of User needs

Download Presentation

Functional and Non-functional requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Functional and Non-functional requirements Specification and Types

  2. Motivation • Short and usable definition: • Essential signs on the rod that lead to a successful project • Formal agreement between client and provider that they have the same goal • Usable representation of User needs • High-quality requirements contribute to: • Keep the project on the schedule • Mitigate business/financial risks

  3. Problem • Creating requirements is a complex task as it includes a set of processes such as elicitation, analysis, specification, validation, and management. • Today we’ll discuss the main types of requirements for software products and provide a number of recommendations for their use.

  4. Level of the requirements • High level: Business requirement • Business view: Why is the project needed? • Mid level: User requirements • User view: What do users need the system do? • Detailed: System requirements • System view: What does the system need to do? High-level requirements cascade down to specific detail

  5. Classification • Business requirements • These include high-level statements of goals, objectives, and needs. • Stakeholder requirements • The needs of discrete stakeholder groups are also specified to define what they expect from a particular solution. • Transition requirements • An additional group of requirements defines what is needed from an organization to successfully move from its current state to its desired state with the new product.

  6. Classification • Solution requirements: Solution requirements describe the characteristics that a product must have to meet the needs of the stakeholders and the business itself. • Non-functional requirements describe the general characteristics of a system. They are also known as quality attributes. • Functional requirements describe how a product must behave, what its features and functions.

  7. Functional requirements • Requirements are usually written in text, may also be visuals, common formats and documents: • Software requirements specification document • Use cases • User stories • Work Breakdown Structure (WBS) (functional decomposition) • Prototypes • Models and diagrams

  8. SRS document • The SRS contains descriptions of functions and capabilities that the product must provide also defines constraints and assumptions. • SRS must include the following sections: • Purpose. Definitions, system overview, and background. • Overall description. Assumptions, constraints, business rules, and product vision. • Specific requirements. System attributes, functional requirements, database requirements.

  9. Use cases • Use cases - Use cases describe the interaction between the system and external users that leads to achieving particular goals. • Each use case includes three main elements: • Actors. These are the users outside the system that interact with the system. • System. The system is described by functional requirements that define an intended behaviour of the product. • Goals. The purposes of the interaction between the users and the system are outlined as goals. • Formats: Diagram or specification

  10. User stories • User story - documented description of: • a software feature seen from the end-user perspective. • what exactly the user wants the system to do. • User stories must be accompanied by acceptance criteria, the conditions that the product must satisfy to be accepted by a user. • INVEST quality model for User stories – • Independent, Negotiable, Valuable, Estimable, Small and Testable

  11. Functional decomposition (WBS) • WBS stands for Work Breakdown structure. • WBS is visual document that illustrates how complex processes break down into their simpler components. • WBS is an effective approach to allow for an independent analysis of each part. • WBS also helps capture the full picture of the project.

  12. Software prototypes • Software prototypes - umbrella term for different forms of early stage deliverables that show how requirements must be implemented. • Traditionally, prototypes represent how the solution will work and give examples of how users will interact with it to accomplish their tasks. • Prototypes can be cheap and fast visual representations of requirements (throwaway prototypes) or more complex ones (evolutionary prototypes)

  13. Non-functional requirements • Non-functional requirements describe how a system must behave and establish constraints of its functionality. • This type of requirements is also known as the system’s quality attributes • Huge Impact on end user expirience

  14. Typical non-functional requirements • Usability - Efficiency of use, Intuitiveness • Security - authorization, data privacy • Reliability – recovery, failover, • Performance - responsiveness of the system, • Availability - up/down, notification, • Scalability - more data/users without negative influence on its performance

  15. Conclusion • All the software projects include the information that describe the product and project goals. • High-quality SRS will facilitate the optimization of the development process. • Software requirement specifications answer all developer’s questions about the product that are required to start the work. • The functional specification is approved by the client and ensures that developers are building what the customer wants.

More Related