September 16, 2014
INSS 615- Mini Paper
Chpt. 1 – Understanding Software Requirements

Software requirements first start off deciding what to build and then how to document the process for designing the specified system needed or acquired. We will discuss what are software requirement, methodologies, requirements and architecture, and emerging trends.
A software requirement is typically classified in two distinct functions. A stated by Thayer and Dorfman (2013) functional typically refers to requirements defining the acceptable mappings between system input values and corresponding output values. Non-functional refers to all constraints including, but not limited to, performance, dependability, maintainability, reusability, and safety. These two functions work intangible with common attributes and similar qualities that behavioral requirements deal with output values and deadlines, and developing quality attributes deals with deadlines and maintaining the goals achieved. One major issue inherent with requirements is discovering significant errors later during maintenance can be very costly. It is recommended to detect errors during the design and development so as is less expensive. The goal of requirements phase is to establish and specify precisely what the software must do without describing how to do it (Thayer and Dorfman, 2013). The ultimate outcome is to specify the problem to be solved and not its solutions. The average person doesn’t understand very technical solutions unless they studied it for a profession, but how to solve the problem. Some of the difficulties that compound the problem are that customer/clients most often do not know what they want or how to describe what the software should do or functions it’s to perform. As well, customer/clients cannot articulate for practical reasons the vision of the software. Also many cannot control the