Requirements+Definition+Sources

=Defining System Requirements=

Preliminary List: cost, automation, level of lighting, size of object, spatial resolution, intersystem compatibility, "gentleness", number of angles, portability, power, spectral bands/wavelengths, resolution, durability, user interface software/hardware, thermal environment, ergonomic issues...

In this section we survey the literature to learn more about system engineering and how it can relate to our project.

=Based on the following external sources:=


 * Maggie Castle**


 * [[file:Requirements Engineering. KotonyaandI and Sommerville,1998.pdf]]
 * [[file:The human factor, Holtzblatt and Beyer, 1995.pdf]]

Retrieved from google scholar.

The System Requirements are what the system should do, they are a serious of requirements that must be met when the system is completed. There are general requirements which give a requirement in broad terms, functional requirements, implementation requirements, performance requirements, and usability requirements(the max time to use the system). The requirements must reflect the needs of the customer and must be complete and clear. The requirements document is a formal statement of the requirements of the system to communicate to the customer, engineers, and workers. This document tells the functions of the systems, and the constraints of the systems. I think understanding these and the importance of the requirements document is important to understand while we create this mechanism to help keep us on track and focused on what has to get done.

The second article describes a customer-centered requirements process where human-dimensions of customer-centered requirements are described. Basically [|requirements definition] is a phrase for “figuring out what to build” and all aspects of the this process ultimately succeed or fail based on how well people can work together. The main human factors described in this article are:


 * ======Human Communication - must talk effectively with each other and all have a clear understanding of the problem, the possible solutions, and the requirements. You have to keep in mind that you may be communicating between people who do not share a common background or job.======
 * Involvement and Control - Everyone must have a mutual involvement and control of the process. No one can feel like they are out of control or lost. The article stressed that each person’s task should be something that they are extremely interested in.
 * Change is Necessary - Make your work customer centered or maybe for this freshman imaging project make the process goal centered. You have to make the fun and change up routines once in a while to help people stay on task.


 * Sam Valerio**
 * [[file:Structured Analysis. Ross and Schoman, 1997.pdf]]
 * [[file:Nuseibeh,Easterbrook, Requirements Engineering-A Roadmap.pdf]]

These articles, obtained via google scholar, give the basic definition of requirements as "Requirements definition is a careful assessment of the needs that a system is to fulfill. It must say why a system is needed, based on current or foreseen conditions, which may be internal operations or an external market. It must say what system features will serve and satisfy this context. And it must say how the system is to be constructed." This definition is saying that requirements definition is determining what the purpose of the system is based on what a market or a company needs, what features will fulfill those needs, and the design plan. Requirements is the first and foremost step in any product development process, and the systems engineering process, at that. It includes three major steps:


 * 1) Context Analysis, which states how the system is going to solve a problem, why the system is needed, what the system will be used for, and it also states why there are certain limitations, such as technical, operational and economic feasibilities, also known as boundary conditions.
 * 2) Functional Specification states how the system will meet its purpose, what the system will be, and what/why certain design components should be looked at.
 * 3) Design Constraints explain how the system will be made in general. It also states the composition of the system, and why particular designs are liable. It does not say specifically what will be part of the system, it just summarizes conditions determining how the system will be created and used, and how boundary conditions will affect what ideas will be selected later in the creation process and incorporated.

This process is crucial to our project, because we cannot start planning what exactly we are going to make without first determining what we are making it for, and what we will need to make it.

Kevin Dickey

 * [[file:Requirements Gathering- the human factor.pdf]]
 * [[file:Creating Products Consumers Demand.pdf]]

Hutchings, Anthony F., and Steve T. Knox. "Creating Products Customers Demand." //Communications of the ACM// 38.5 (1995): 72-80. //Academic Search Elite//. EBSCO. Web. 21 Sept. 2010.

This article examines a case study of a new type of requirements definition process for an upcoming product at Digital Equipment Corporation, a firm that engineered microprocessors and other computer hardware. The authors designed their new system around customer satisfaction, in addition to just the usual specifications-related goals. The firm started by changing from a technology-centric view of products to one that focuses on the consumer’s experience of using the product. A program, called AEE (Achieving Engineering Excellence) was created within the company to study the specifics of Digital Equipment’s development processes. It found that cross-functional teams (those who serve multiple purposes) reduce misunderstandings in a project, and reduce the amount of time it takes to correct any mistakes. Such teams had clearer requirements definition, leading to a reduced risk of making changes to a product late in its development. Also aiding in the development process was a high level of direct contact with customers. The company defines requirements management as a process that “involves establishing and maintaining an understanding and agreement with the customer on the requirements for the software throughout the lifecycle”, something which is reflected in both the technical specifications and the user interface of a product. Digital Imaging produced a simple model for their requirements definition process, a circular model made up of three main parts – listen, define, validate. Listen to customers, partners, engineers, marketers, etc. Then define the specifications of a particular product based on what is heard. Once a product has been created, validate that specification definition with real-world testing of prototypes, and then repeat the cycle all over again. Beyond that, Digital Imaging created a nine-step requirements definition process:
 * 1) Understand system business needs. Create a multidisciplinary team, and begin to identify target markets and specific customer contacts to aid in the requirements definition for the product.
 * 2) Gather customer information. Gain information from anybody who may be connected to the product. This can include customer surveys, focus groups, and advisory boards, as well as the examination of real-world applications in the work environment of the customer.
 * 3) Translate needs into an internally consistent list of requirements. This is fairly self-explanatory – take the information collected from customers, and use it to create requirements for the product.
 * 4) Develop and prove key enabling concepts. In this step, designers of a product determine which technology will best fit the needs of the product, and how it may be designed.
 * 5) Compare chosen solutions against the competition. What does the new design do that competitors won’t? Is it more effective? With the strengths of this technology identified, marketing becomes much easier when the product is finished.
 * 6) Define top-level subsystem dependencies and commitments. How are the various teams connected? Who is dependent upon whom?
 * 7) Freeze product requirements. Product specifications have been designated based on the last 6 steps; it is now time for development. Changes to the design at this point will be very expensive.
 * 8) Determine impacts of proposed change. Changes may occur to the product during development. What benefits does this have? How much will these benefits cost?
 * 9) Update product requirements definition. Allow users to test prototypes and gain real-world knowledge about their performance. Update the requirements of the product as necessary.

Holtzblatt, Karen, and Hugh R. Beyer. "REQUIREMENTS GATHERING: The Human FACTOR."//Communications of the ACM// 38.5 (1995): 30-32. //Academic Search Elite//. EBSCO. Web. 21 Sept. 2010.

The authors of this article argue that, in order to have a successful requirements definition process, we must be attentive to “the human dimensions”. The process is, after all, about talking and communicating with other individuals to determine their needs. Yet it is also about communication between customers and designers to develop a mutual understanding of the product to be created, team members communicating concepts to each other, and the managers who communicate to link the various teams together.

“Effective requirements of definition requires involvement and mutual control of the process by all players”, state the authors. Customers do not like to be told //how// to work, or being confined to a particular way of working. They must tell designers how //they// work. Direct customer involvement in the product development process is the only way to design a more effective product. Collaboration between users and designers is not merely beneficial to the product; it allows the user to incorporate the new product into his everyday work. The success of a product, in the end, is largely determined by its designers’ attentiveness to its “human dimension”.


 * Nadya Spice**
 * [[file:10 requirements management.pdf]]

This source provides a universal 3-step process to the development of project requirements:


 * 1) identify appropriate requirements
 * 2) maintain set requirements
 * 3) control changes to requirements

In regards to the "big picture" of the project, a contract is said to always be involved. At least two documents will be needed to write up a contract for the project. A statement of work and a work breakdown structure help to outline contracts, and are necessary for such development (included below):


 * [[file:10 requirements sow.pdf]]
 * [[file:10 Work Breakdown Structure.pdf]].

This source mostly refers to the aids of a Statement of Work and a Work Breakdown Structure as the most helpful resources for requirement definition, and with the use of them a basic understanding will be established. I see the application of this process to be a dangerous field for our task. Looking at a project in terms of the final product helps with motivation as well as requirements definition, but it can also lead to overlooking important and specific details. Having an end product in mind might block off room for creativity and, in turn, hinder our ability to come up with new ideas. This source focuses on an approach to requirements definition called "Spiral Acquisition." The process of Spiral Acquisition is based upon establishing levels of capability. Much like any spiral structure, each additional layer builds upon the last, in an ongoing pattern. Each spiral includes its own project or two that will help move on to the next step in the process of developing requirements. This process seems to be efficient and organized. We can definitely apply it to our development of a PTM because we are already in the process of our own spiral acquisition. Each small assignment we have accomplished comes together to be the base of a spiral, and as we each get into more specific areas of the development of a PTM, we will continue to build our own spirals, that will again come together as our final product.
 * [[file:10 requirements pdf spiral .pdf]]


 * Dan Goldberg**
 * [[file:Federal Financial Management System Requirements.pdf]]
 * Enabling Software Development Team Performance During Requrements Definition

__Federal Financial Management System Requirements__

This document was written by the Joint Financial Management Improvement Program (JFMIP) in order to “assist agencies when developing new benefit systems and when improving or evaluating existing benefit systems”. A benefit system is described as a mixed (financial and non-financial) system which administers benefit programs. The term “benefit” relates to government programs such as food stamps, Medicare, veteran health care, and so on (9). Though this document talks about requirements for a system of programs instead of a technical system, it is still relevant to our class. The JFMIP broke down the system into its major functions (11):
 * 1) Claims Acceptance and Tracking
 * 2) Claims Processing
 * 3) Benefit Payment Administration
 * 4) Recovery Receivable Management
 * 5) Accounting for Benefit Transactions
 * 6) Financial Rep_o.r. tiFg
 * 7) Interfaces
 * 8) Quality Assurance and Maintenance
 * 9) Technical Functions

For each function, there are base “Mandatory Requirements” and “Value-Added requirements”. The document does not say how the system must carry out these requirements, only what the basic needs for each section are. For example: under Mandatory Requirements, the document reads, “To support the claims acceptance and tracking functions, the benefit system **__must:__** Capture all of the mandatory data elements specified in the ‘Application Information Store’…”(13). Under “Value-Added Requirements” it reads,

To support the claims acceptance and tracking process, the benefit system **__should:__**

Maintain a system record of pending claims and the status of other information including:
 * where in the process an ongoing claim is located;
 * who is holding claim;
 * what actions are needed to complete the claim;
 * whether additional information is needed; and
 * accommodation of explanation codes to indicate the reason why the claim is pending (14).

For our requirements definition we must focus on the same things. We should have base mandatory functions as well as requirements that it “should” have. For this step, we do not need to worry about how we can achieve the requirements only what to actually make our requirements.