Software requirement

from Wikipedia, the free encyclopedia

A software requirement is a requirement in the context of software development . The requirement includes the purpose and intent of a software system, as well as its (external) behavior.

Types of software requirements

A basic distinction is made between software requirements:

Business needs
Targets that result from the customer's business activity and market requirements. Business requirements are defined by management and marketing.
User requirements
The requirements necessary for the users of the software system to be able to meet the business requirements. Here it is defined which user groups exist, which business processes change how for the respective user, as well as suitable metrics to record these goals. The user requirements are defined by business analysts, users or representatives of the users, as well as product managers.
Functional requirements
Capture the behavior that a software system should have in order to meet user requirements. Functional requirements are defined by business analysts and product managers in consultation with software development and the test department.
Project requirements
The requirements necessary for the success of a project in order to be able to implement the functional requirements and to be able to support the product in the course of Application Lifecycle Management (ALM). These include, for example:
  • Hardware, deployment environments, software licenses for development tools, premises
  • Employees and training
  • Documentation of the software system for users, training and support staff
  • Quality requirements and service level agreements (SLAs)
  • Legal requirements (including licenses, patents, trademark law, copyright law)

format

Software requirements process

The task of the requirements manager is to collect the requirements and possibilities together with the stakeholders involved (e.g. users or "surrogate users", customers , as well as product owners and development teams ) and to translate them into a form that software developers can understand. This is done formally in the form of user stories , which are broken down into functional requirements and, with the help of a software developer, translated according to Gherkin syntax, as well as in the form of UML diagrams, which are more precisely defined by a software architect .

Requirements that are only recorded verbally, through voicemail , on sticky notes, e-mails, transcripts from meetings, or similarly unstructured, do not belong to the catalog of requirements of the software system that a developer has to implement. These requirements must first be recorded in a structured manner by the business analyst.

A software system sees the requirement as a black box and defines the purpose of the individual sub-requirements as well as associated application examples from the point of view of the different user groups.

The software requirements must be managed in a living documentation . A version management system should be used to enable traceability . A contact person and the associated contact details should also be known for partial requirements. It should also be recorded in an issue tracking system , at what point in time, by which interest group and for what reason a request was made and changed. In the event of program errors and change requests in the system, the actual status and behavior as well as the target status and behavior should be documented.

Software requirements from the customer's point of view

In the book Software Requirements , Karl Wiegers defines the rights and obligations of the customer, which should be complied with when creating requirements:

Customer rights
  1. Business analysts use customer jargon.
  2. Business analysts learn the client's business processes and goals.
  3. Business analysts capture the requirements in such a way that they can be provided in a form suitable for the customer.
  4. Right to information about the purpose of certain requirements and deliveries.
  5. Changes in requirements.
  6. Right to mutual respect.
  7. Information for alternative ideas from the service provider.
  8. Requirements for ease of use.
  9. Information about possibilities to accelerate the development by adapting the requirements so that existing software components can be used.
  10. Delivery of a system that meets both the functional requirements and the quality requirements.
Obligations of the customer
  1. Educating the service provider about the business processes.
  2. Planning the time that is needed to provide and improve the requirements.
  3. Creation of specific and precise requirements.
  4. Make decisions and provide information on requirements within appropriate time periods.
  5. The developers' assessments of the time required and the feasibility of a requirement must be respected.
  6. Realistic prioritization of requirements in consultation with the developers.
  7. Regular reviews of requirements and the evaluation of prototypes.
  8. Definition of acceptance criteria in consultation with the customer.
  9. Communicate changes to requirements quickly.
  10. Adhering to the process of collecting the requirements.

Challenges

Documents with software requirements can be very extensive and, depending on the product, comprise hundreds to thousands of pages of documentation. In practice it is impossible to formulate the requirements completely or without contradictions. Gaps and contradictions are usually only discovered during development or in production. In addition, the requirements usually change during the development of a software product.

Further difficulties arise from the fact that with specifications in the usual:

  • insufficient information is provided for development
  • limited to the knowledge of a few people and affected interest groups are not sufficiently involved
  • Information is lost in the translation of customer needs into requirement
  • Business goals to be achieved (intent) are neglected and the focus is too much concentrated on technical details (concrete implementation)
  • a natural language is used which has to be interpreted and interpreted
  • certain conditions are given or taken for granted and are therefore not mentioned
  • Small errors and changes accumulate, which means that the requirement and implementation diverge more and more as the project progresses

Studies show that 40% to 50% of all errors in software systems are caused by an incorrect request. In 2004 alone, 142 billion euros were lost in the European Union due to failed software projects. The majority of this can be traced back to software requirements that were not sufficiently aligned with the business goals or that the business goals have changed. In addition, 30% to 50% of the project costs are caused by changes in requirements and associated product changes. Of these changes, 70% to 85% are caused by errors in the request.

Agile software development reduces these problems through regular communication between interest groups, but is affected by the same effects.

Because of these challenges, communication must be as precise as possible. In addition, processes must be provided for changing the requirements if necessary. In addition, the requirement should be automatically verifiable so that the requirement is consistent at the time the software is completed and corresponds to the behavior of the software developed.

scope

Software requirements include:

  • Programming interfaces
    • Descriptions (English: contracts )
    • behavior
    • Binding (English: binding ; protocol, encryption etc.)
    • Addresses
  • References to requirements from other systems
  • Form and scope of the required user documentation
  • Information requirements
    • Data types and data structures
    • Requirements for unique identifiers (IDs, GUIDs , URIs , URNs , clean URLs )
    • Calculation formulas
    • Type of data persistence and lifetime of data
    • Fields that are required for an entity
    • Requirements for data transactions (taking into account the CAP theorem )
    • Data for which a history must be recorded
      • Version management
      • Security and Compliance Auditing
    • Data storage infrastructure
    • Data archiving
    • Data recovery in the event of a disaster
    • Locality of the data (e.g. end device, data center, cloud, business partner, public, regional restrictions)
  • Configuration of the application
  • Performance requirements
    • Response times
    • Throughput
    • Static capacity limits
    • Dynamic capacity limits
    • Availability requirements
  • Flexibility requirements
    • Scalability
    • Expandability
    • Unparochiality (independence from the infrastructure)
    • Diversity (provision of data for other systems)
    • Internationalization (i18n)
      • Multilingualism
      • Dealing with time zones, as well as leap seconds and hours
      • Currencies
      • Reading direction
      • Cultural symbolism
      • Regionally different legal requirements
  • Commercial requirements
    • Organizational forms of the companies that use the software product (e.g. ITIL )
    • Legal guidelines (e.g. tax calculation , SOX )
  • Stability requirements and fault migration
    • Behavior in the event of overload or failure of an external system (e.g. backup , bulkheads and connection pooling)
    • Representation of errors or restricted functionality from the user's point of view
    • Behavior in the event of an error in an instance of the system (e.g. dynamic routing)
    • Identification of critical systems for the respective business processes, as well as possible single point of failure
    • Throughput rate limits
  • Division into partial requirements
    • Definition of minimum requirements and objectives (must, should, could and not requirements; see also: RFC 2119 , RFC 6919 )
    • Prioritization of requirements
    • Division of responsibilities into separate systems (e.g. user management, ordering, goods management, delivery, administration, business intelligence)

Implicit software requirement

An implicit software requirement is a requirement that must be implemented, but was not explicitly specified by requirements management. This mostly concerns requirements for testability (e.g. test coverage through unit tests ), security (e.g. encryption) or application lifecycle monitoring (e.g. logging).

literature

  • Stephen Withall: Software Requirement Patterns (Developer Best Practices) . Microsoft Press, 2007, ISBN 978-0-7356-2398-9 (English, 384 pages).
  • Karl E. Wiegers: Software Requirements (Developer Best Practices) . 3. Edition. Microsoft Press, 2013, ISBN 978-0-7356-7966-5 (English, 672 pages).
  • Karl E. Wiegers: More About Software Requirements: Thorny Issues and Practical Advice (Developer Best Practices) . Microsoft Press, 2006, ISBN 978-0-7356-2267-8 (English, 224 pages).
  • Michael T. Nygard: Release It! Design and Deploy Production-Ready Software. O'Reilly, 2007, ISBN 978-0-9787392-1-8 (English, 326 pages).
  • Christine Rupp: Requirements engineering and management: From practice from classic to agile . Carl Hanser Verlag GmbH & Co. KG, 2014, ISBN 978-3-446-43893-4 (570 pages).
  • Ulrike Hammerschall, Gerd Beneken: Software Requirements . Pearson Studium, 2013, ISBN 978-3-86894-151-7 (432 pp.).
  • Gojko Adzic: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing . Neuri Limited, 2009, ISBN 978-0-9556836-1-9 (English, 284 pages).
  • Gojko Adzic: Impact Mapping: Making a Big Impact with Software Products and Projects . Ed .: Marjory Bisset. Provoking Thoughts, 2012, ISBN 978-0-9556836-4-0 (English, 86 pages).

swell

  1. ^ A b c Karl E. Wiegers: Software Requirements (Developer Best Practices) . 3. Edition. Microsoft Press, 2013, ISBN 978-0-7356-7966-5 (English, 672 pages).
  2. ↑ a b c d e Gojko Adzic: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing . Neuri Limited, 2009, ISBN 978-0-9556836-1-9 (English, 284 pages).
  3. ^ Alan M. Davis: Just Enough Requirements Management: Where Software Development Meets Marketing . Computer Bookshops, 2005, ISBN 978-0-932633-64-4 (English, 240 pages).
  4. ↑ a b Gojko Adzic: Impact Mapping: Making a Big Impact with Software Products and Projects . Ed .: Marjory Bisset. Provoking Thoughts, 2012, ISBN 978-0-9556836-4-0 (English, 86 pages).
  5. ^ Forrest Shull, Vic Basili, Barry Boehm, A. Winsor Brown, Patricia Costa, Mikael Lindvall, Dan Port, Ioana Rus, Roseanne Tesoriero, Marvin Zelkowitz: What We Have Learned About Fighting Defects. (PDF) Accessed June 12, 2017 (English).
  6. ↑ Stronger Management Practices Are Needed to Improve DOD's Software-Intensive Weapon Acquisitions. US Government Accountability Office (GAO), March 1, 2004, accessed June 12, 2017 .
  7. ^ Dean Leffingwell: Calculating the Return on Investment from More Effective Requirements Management. In: American Programmer. Institute for Software Quality (IFSQ), 1997, accessed June 12, 2017 .
  8. ↑ Stephen Withall: Software Requirement Patterns (Developer Best Practices) . Microsoft Press, 2007, ISBN 978-0-7356-2398-9 (English, 384 pages).
  9. ↑ User impersonation. Auth0, accessed April 10, 2017 .