Functional And Non-Functional Requirements

  • Published on
    21-Jul-2016

  • View
    36

  • Download
    5

Embed Size (px)

DESCRIPTION

Functional and non-functional requirements.

Transcript

  • 1

    INTRODUCTION

    Software Engineering is an engineering discipline concerned with all aspects of software

    production, from the early stages of system specification through to maintaining the system after

    it has gone into use. Contained in Software Engineering is a further concept Requirements

    Engineering.

    Requirements engineering is the practice of establishing the services that the customer needs

    from a system and the constraints under which it operates and is developed. The requirements

    for a system themselves are the descriptions of what the system should do the services that it

    provides and the constraints that are generated during the requirements engineering process.

    These requirements tend to reflect the essential needs of customers for a system that serves a

    certain specified purpose. Requirements may range from a high-level abstract statement of a

    service or of a system constraint to a more detailed mathematical functional specification.

    Focus is given to two main types of requirements user requirements and software system

    requirements. Software system requirements are commonly presented as a structured

    document that lays out explicit descriptions and explanations of the systems functions, services

    and operational constraints. They help define exactly what needs to be implemented in the

    software to be developed, and therefore they are usually part of a contract signed between the

    client and the contractor. Software system requirements are often classified as functional

    requirements or nonfunctional requirements.

  • 2

    FUNCTIONAL REQUIREMENTS

    Functional requirements refer to very important system requirements and statements of services

    in a software engineering process the system should provide, how the system should behave in

    reaction to particular inputs and how the system should perform when presented with specific

    situations. When expressed as user requirements, functional requirements are usually described

    in an abstract way that can be understood by system users. However, more specific functional

    requirements may contain calculations, technical details, data manipulation and processing and

    other specific functionality that define what a system is supposed to accomplish, and sometimes

    might specify what the system should not do. The key goal of determining functional

    requirements in a software product design and implementation is to capture the required

    behavior of a software system in terms of functionality and the technology implementation of

    the business processes.

    Normally, the Software Engineer makes use of the Use Cases and Scenarios generally following

    standard UML notations, in order to capture the functional requirements through a system

    analysis process. A typical functional requirement will contain a unique name and number, a brief

    summary, and a rationale. This information is used to help the reader understand why the

    requirement is needed, and to track the requirement through the development of the system.

    As functional requirements must specify particular results of a system, the description of the

    required behavior needs to be completely clear and readable. The described behavior may come

    from organizational or business rules, or it may be discovered through elicitation sessions with

    users, stakeholders, and other experts within the organization. Many requirements may be

    uncovered during the use case development. When this happens, a placeholder requirement

    with a name and summary may be created and the details researched later, to be filled in when

    the requirements are better known.

  • 3

    Functional requirements are usually in the form of "system shall do ", an individual

    action of part of the system, perhaps explicitly in the sense of a mathematical function, a black

    box description input, output, process and control functional model or IPO Model.

    An example of a system using functional requirements is the list of a possible Sales applications

    functional requirements as shown:

    1. Application shall capture appropriate information and produce Comparative Analysis

    (current month and year-to-date compared to same month last year and year-to-date last

    year) and Trend Analysis reports by: Product (units sold and dollars), Product Type,

    Product Family, Customer, Salesman, Territory, and Discount Type.

    2. Application shall show Trend Analysis by Customer and Product, including profitability by

    customer.

    3. Application shall show Trend Analysis by Product and Customer, including profitability by

    product.

    4. Application shall show Monthly Detail by Customer and Invoice.

    5. Application shall show Graphic Trend Charts by Customer, Salesman, Product Type and

    others.

    6. Application shall show Sales of Products by Vendor, by Postal Code.

    7. Application shall show Sales by Source Code (for Mail Order companies).

    8. Application shall show Sales Analysis by province

  • 4

    NON-FUNCTIONAL REQUIREMENTS

    In requirements engineering, a non-functional requirement is a requirement that specifies the

    standards that can be used to judge a systems operation, rather than specific behaviors.

    Basically, non-functional requirements define how a system is supposed to be as opposed to what

    it is supposed to do. They are generally informally stated, often contradictory, and difficult to

    enforce during development and evaluate for the customer prior to delivery. They are usually

    specified or constrained by the characteristic behavior of the required software, system

    requirements derived from policies and procedures in the customers and developers

    organization, or from external sourceswhich includes all requirements that are derived from

    factors external to the system and its development process.

    Non-functional requirements define system properties and constraints (for example reliability,

    response time and storage requirements), and requirements instructing a specific IDE,

    programming language or development method may be detailed. They may be more critical than

    functional requirements in the sense that if non-functional requirements are not met, the system

    may be rendered practically useless.

    Non-functional requirements drive the technical architecture of a system, which means that they

    tend to affect the whole architecture of a system, as opposed to only the separate specific

    components. For instance, to ensure that optimum performance requirements are met, the

    system might need to be arranged in such a way that communications amid components are

    lessened, eliminating unnecessary communications. A single non-functional requirement may

    spawn several related functional requirements that define required system services, and may

    also generate requirements that restrict existing requirements.

    In order to specify efficient non-functional requirements, there are a few merits that must be

    considered. These include the system's availability or "uptime" (the amount of time that it is

  • 5

    operational and available for use), efficiency (specifies how well the software utilizes scarce

    resources), flexibility (enables the organization to extend the functionality of the software after

    it is deployed), portability (specifies the ease with which the software can be installed on all

    necessary platforms, and the platforms on which it is expected to run), integrity (defines the

    security attributes of the system, restricting access to features or data to certain users and

    protecting the privacy of data entered into the software), performance (specifies the timing

    characteristics of the software), reliability (specifies the capability of the software to maintain its

    performance over time), reusability (indicates the extent to which software components should

    be designed in such a way that they can be used in applications other than the ones for which

    they were initially developed), robustness (enables the system to handle error conditions

    gracefully, without failure), scalability (gives the ability to handle a wide variety of system

    configuration sizes), and usability (addresses the factors that constitute the capacity of the

    software to be understood, learned, and used by its intended users).

    Non-functional requirements appear in the form of "system shall be ", an overall

    property of the system as a whole or of a particular aspect and not a specific function. The

    diagram below provides an example of non-functional requirements as implored in a proposed

    solution for a general application.

  • 6

    CONCLUSION

    Functional requirements drive the application architecture of a system, while non-functional

    requirements drive the technical architecture of a system. The functional requirements describe

    the behavior of the system as it relates to the system's functionality, while the non-functional

    requirements elaborate the performance characteristic of the system. If there is any one thing

    any project must have in order not to be doomed to failure, it is a sensible and comprehensive

    collection of both the functional and non-functional requirements. Any projects requirements

    need to be well thought out, balanced and clearly understood by all involved, but perhaps of

    most importance is that they are not dropped or compromised halfway through the project.

  • 7

    REFERENCES

    Debono, M. (2012, April 5). Functional Requirements vs. Non-Funtional Requirements. Retrieved from ReQTest: http://www.reqtest.com/blog/functional-vs-non-functional-requirements/

    Functional Requirements. (2008, February 6). Retrieved from Toolbox.com:

    http://it.toolbox.com/wiki/index.php/Functional_Requirements Sommerville, I. (2011). Software Engineering. Boston, Massachusetts: Pearson Education Inc. Stellman, A. (2010, February 17). Understanding Nonfunctional Requirements. Retrieved from

    O'Reilly Community: http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.html

Recommended

View more >