There are many sources in systems engineering and requirements engineering that use the term “attribute,” but few define the term and fewer actually go into any detail regarding how the attributes might be applied to requirement statements. This paper addresses the inconsistent definition and use of the term as part of the systems engineering and requirements engineering processes. We discuss the importance of defining requirement attributes and offer a useful definition. We provide a possible list of attributes along with their meaning, in order to provide a useful set of attributes that organizations may include with requirement expressions to manage better their requirements. Finally, we discuss how attributes can be used to manage not only requirements and sets of requirements, but also the project.
Abstract. Requirements have a big impact on project success. Studies show the importance of having a good set of requirements that are clear, complete, correct, and consistent as well as the consequences of not having a good set of requirements. Having poor requirements places projects at risk of significant cost overruns, schedule delays, and performance shortfalls. In fact, recent studies have shown that projects who fail to take effective actions to ensure a good set of requirements triple their chances of project failure. The emphasis of this paper is to identify common requirement development and management risks that can have an impact on a project's success, possible consequences of these risks, and strategies to mitigate the risks and avoid the consequences of those risks. Recognizing the fact that poor requirements represent a significant risk to your project and mitigating these risks can triple your chances of project success. Risk and RequirementsRecognizing the importance of a disciplined approach to product development and the need to define a good set of requirements so projects can be successful, various organizations responsible for creating product development and system engineering processes have defined processes based on best practices in industry and government. These processes are documented in various standards (see references) all of which stress the importance of upfront processes for defining product scope and requirements. The result of following these processes is a set of requirements that describe the characteristics, capabilities, functionality, performance, and quality the system needs to have to meet stakeholder expectations. These requirements provide the foundation upon which the product design is based. With this emphasis on requirement development and management, it is logical to assume that project managers would want to avoid the risks associated with having a poor set of requirements. Therefore it is logical to assume these project managers would follow proven best practices to ensure a set of well-written requirements is established before contracting the design and development of their product. Unfortunately, this does not happen as often as it should. Many managers continue to fail to place the proper emphasis on having good requirements and communicating the importance of good requirements to their project team. Because of this, many projects are being set up for failure from the beginning, tripling their chances of project failure. NASA's Office of Inspector General (OIG) November 2008 report [OIG 2008] focused on five major challenges; one of which concerns acquisition and contracting processes. The OIG concluded that: "NASA must be vigilant in its process of establishing and validating project requirements." Program risks increase when contractual obligations are established before developing a sound business case and clearly defining requirements; placing "the project at risk of significant cost overruns, schedule delays, and performance shortfalls. Effective risk ...
Some of the biggest problems in developing a system are at an interface. Some of the most critical requirements for every system that we build are interface requirements. Interface requirements cannot be written in a vacuum, both sides must participate. Yet how to write interface requirements is barely covered in the literature -and what is in the literature is not consistent. This paper will address some things you can do to get better interface requirements. Topics covered include: Understanding what constitutes an interface, how to identify interfaces, how to define and document interface definitions, what constitutes a good interface requirement, and where and how to document interface requirements. 132Examples of misunderstanding what an interface is and is not
Requirements are the language we use to communicate stakeholder needs for a system of interest to developers, designers, builders, coders, testers, and other stakeholders. Increasingly, there is debate about which means (form and media) of communications is best for communicating requirements and sets of requirements. As part of this debate, one means of communication (such as diagrams, use cases, or text‐based) is often advocated (with a lot of passion in many cases) over the other means of communication. Which side is taken in the debate depends on the specific idea or concept being communicated together with the domain, culture, people, and processes used within the specific organization. Consequently, there is no single “best” means of communication that applies to all the various types of requirements. Each means of communication has its strengths and weaknesses depending on which message is being communicated, who the sender is, who the receiver is, the needs of the receiver, and the filters used by both the sender to encode the message and the receiver who must decode the message. This paper goes back to the basics of communication theory to address this debate and concludes that, while each means of communication has value, no single means is sufficient to clearly, completely, and consistently communicate all of the various types and categories of requirements. Each of the means advocated represent a visualization (graphic or text) of the system from a perspective based on the intent of the message being communicated. With this viewpoint, rather than focusing on a single type of visualization, a set of visualizations is needed to effectively communicate requirements. This set of visualizations needs to be based on an underlying, integrated data and information model of the system of interest.
The purpose of a requirement expression is to communicate clearly the needs of various entities into a formal language such that the intent is clearly understood by all involved: those whose job it is to implement the requirement, those responsible for proving the built system meets the requirement, and those responsible for proving the resulting system meets the needs of the relevant entity. Although many sources provide definitions of the terms associated with a requirement expression, there are only occasional agreements on common definitions, and the defined terms are too narrowly focused to be useful across the full requirements engineering domain. This paper proposes a cohesive set of definitions of the terms associated with a requirement expression. First, a framework for the transformation of needs into requirements is briefly discussed and existing definitions are presented from major relevant sources. These definitions are then analyzed and a cohesive set of definitions is offered for the key terms associated with a requirements expression: entity; need; requirement statement; and the requirement attributes that, along with the requirement statement itself, comprise the requirement expressions in a requirement set.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.