Requirements++Allocation

The main goal of requirements allocation is to ensure an increase in the systems ability with minimal design changes. This article focuses on R&M requirements allocation which applies to upgrading technical systems. This model is based off of a mathematical model that describes dependences of the system and subsystems and focuses around availability. The article focuses on its application to heavy tracked vehicles in the Czech Republic’s army. I think that this article is a good tool because although its process can be very confusing with all the math that is happening, understanding the idea of increasing the systems ability with minimal changes is important for when we find changes that may need to be made in the middle of our project.
 * Maggie Castle**
 * [[file:Requirements Allocation 1.html]]


 * [[file:Allocation Requirements 3.html]]

All system level performance requirements must be flowed down and assigned to lower level functions of the work breakdown structure. This is requirements allocation. The process described in this article tries to flow-down requirements to best meet the customers needs. This process offers opportunities for various solutions and creativity which many do not all while focusing on the needs and desires of the customer. There is a three step method for requirements allocation which follows: I feel that allocation requirements is important to our project because once we determine the overall requirements of our PTM system and design our Work Breakdown Structure, we must then assign requirements to all the subsystems of our product. This approach would be helpful to keep our creativity while still trying to follow all our requirements for our multiple users.
 * 1) explicit requirements and quantified values for important product characteristics
 * 2) list of potential design solutions for each subsystem and their impacts on those requirements important to the customer
 * 3) optimizes sub-allocations of the overall requirements using a linear-integer program to determine the selection of subsystem design solutions which maximizes benefits.

** Kevin Dickey ** >
 * [[file:Optimized Resource Allocation for Software Release Planning.pdf]]
 * [[file:A distributed solution for resources allocation to overlapping groups.pdf]]

Cheng, Zixue, Y Wada, Yao Xue Zhang, and S Noguchi. "A Distributed Solution for Resources Allocation to Overlapping Groups." //Parallel and Distributed Systems, 2000. Proceedings. Seventh International Conference on//, (2000):.

This author argues that, within each system, there are a set of processes and a set of resources. All processes require some of the limited resources, which must be procured by certain groups in order to carry out their duties. But if a single group takes certain resources, then those resources aren’t available to other groups that may need them; this is called “starvation”. Conversely, “deadlock” occurs when no groups can use resources. Naturally, both of these states must be avoided in the efficient development of products. The author presents a solution, “Distributed Allocation of Resources to process Group” (DARG). In this solution, more than one group may still share a common process. By satisfying three (very complex) conditions, it can be ensured that multiple groups are not attempting to use the same resources simultaneously.

Ngo-The, An, and G Ruhe. "Optimized Resource Allocation for Software Release Planning." //Software Engineering, IEEE Transactions on//, 35.1 (2009): 109-123.

This author describes the complexities of resource allocation in software design. In the design process, it is assumed that each developer is working on only one task at a time. If numerous developers were needed to work on a task, it would be further decomposed so that each developer would have only one assignment. To account for the variability in skill level of developers during the task-assignment process, “an average skill level with a normalized productivity factor of 1.0” for each developer is introduced for each type of task. Using this, managers can make effective choices about which employees to assign to each task. These productivity factors make it easy to assign jobs, as a worker’s indicated productivity factor will likely be representative of their usefulness on a specific type of job. With this tool, human resources are allocated effectively, the author argues.

**Sam Valerio**

(both obtained via Google Scholar)
 * [[file:Task Allocation Model, Ma&Lee&Tsuchiya, 1982.pdf]]

This article discusses a method of requirements allocation called the FAR approach (Functional Architecture by use case Realizations). It particularly emphasizes a part of this method called "use-cases" which from what I gather are a functional analysis technique that allows turning system functionality into user goals, whether they be large or small goals. Using these "use case scenarios," the FAR approach goes into its main function called the "Perform Functional Analysis and Allocation" function. In this process, project managers first develop a Functional Breakdown Structure, a WBS, like our team has already researched, to determine the major systems and subsystems in the final finished project. Then, use cases, or goals, need to be identified. Using these goals, use case scenarios are developed, or how a group will go about reaching the goals. Managers will then specify which scenarios are the most probable ones, and then come to realizations of which ones will be reasonable to use in the project. The last step is the requirements allocation process, where a group allocates quality attributes to the subsystems. Then the group can go on to complete a requirements allocation sheet, which states all of the system requirements and how they will be distributed. In creating our PTM device, it is important that we make this FBS, set goals and sub-goals, determine how these goals will be reached in the most efficient way possible, and determine what aspects of the project that the requirements of the imaging system will belong to. This FAR approach may be a great way to ensure this series of steps is completed.
 * [[file:The FAR Approach, Eriksson&Borg&Borstler, 2006.pdf]]


 * Dan Goldberg**
 * [[file:Allocation of the Reactive Power Support Requirements in Multitransaction Networks.pdf]]
 * [[file:Quick decision-making support for inspection allocation planning.pdf]]

These articles give two examples of different ways to allocate resources in order to meet requirements. For our project, we need to make sure we are able to achieve all of our requirements. In order to do this, we need to allocate our resources (time, physical resources, students).