On the scenario given the conversation between the systems professional, John Juan and a manager of a department targeted for a new information system, Peter Pedro. On the part of John Juan, he wants the way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then they can determine which aspects are working well and which should be preserved. In his part getting the requirements right – and getting the right requirements – can mean the difference between a successful project – one that satisfies the needs of its users and is delivered on-time and on-budget – and one that fails.
It should come as no surprise that effective requirements gathering involves much more than asking business users what they want and need. It is a complex process that involves users and system designers in a collaborative effort that explores both functional requirements and the new possibilities that technology offers.
On the part of Peter Pedro, he says that he would feel much more comfortable if we first started with a list of our requirements. They should spend some time up-front determining exactly what we want the system to do for my department. Then they systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system. In his point of view, listing requirement would satisfies the need of the company and spend time on determining what system can help to the department. But for me, it is spend time to nothing and wasting of money.
With this scenario I will go to the part of John Juan because an effective requirements gathering process is perhaps the most critical driver of software project success. The analysis begins with a review of the categories of information process. With this System Requirements Analysis can be a challenging phase, because all of the major Customers and their interests are brought into the process of determining requirements. The quality of the final product is highly dependent on the effectiveness of the requirements identification process. Since the requirements form the basis for all future work on the project, from design and development to testing and documentation, it is of the utmost importance that the Project Team creates a complete and accurate representation of all requirements that the system must accommodate. Accurately identified requirements result from effective communication and collaboration among all members of the Project Team, and provide the best chance of creating a system that fully satisfies the needs of the Customers. The primary goal of this phase is to create a detailed Functional Specification defining the full set of system capabilities to be implemented, along with accompanying data and process models illustrating the information to be managed and the processes to be supported by the new system. The Functional Specification will evolve throughout this phase of the SDLC as detailed business requirements are captured, and as supporting process and data models are created, ensuring that the eventual solution provides the Customers with the functionality they need to meet their stated business objectives.
Functional requirements also help to obtain a successful project. It may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describing all the cases where the system uses the functional requirements are captured in use cases. Functional requirements are supported by non-functional requirements (also known as quality requirements), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). How a system implements functional requirements is detailed in the system design. On the other hand a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.
Some Run-time non-functional requirements arise from the operating environment, the user(s), and competitive products:
System Constraints. Here one is looking for elements of the environment into which the system must fit, that may serve as constraints on the system. This may be true of the installed infrastructure (e.g., hardware and OS platforms) or legacy applications, or may be in the form of organizational factors or the process that the system will support.
User Objectives, Values and Concerns. In establishing the run-time qualities for a system, it is important to identify all the categories of user (including other systems) that will interact with the system, and understand what quality attributes they care about. A quality attribute such as performance may surface for one user as a concern, and another as a value, so it is useful to direct elicitation of both values and concerns for any (group of) user(s). It is important to focus on creating just what users want, with the qualities they care about—low priority whiz-bang features or qualities only increase complexity for the development organization and/or for the user. The requirements team should nonetheless be alert to requirements that users take for granted or are not able to articulate directly. Understanding the users’ objectives and forces that impact their success and sense of utility, will help surface and establish the priorities of system qualities— as well as functionality, of course.
There a lot of method helpful on the system. In the purpose of this system requirements analysis, it provides a sound basis for a specification of the system architecture, an architecture that will both satisfy immediate requirements and will be scalable and expandable to accommodate future needs.
In the purpose of Defining a Process Model is to create a pictorial representation of the functions and operations (i.e.,the processes) that will eventually be performed by the system being developed. Define the Process Model may begin at any time after the Project Team has started collecting specific business requirements. The resulting Process Model of the system, also often referred to as the “To Be” model, illustrates the system processes as they are envisioned for the new system. Over time, this pictorial top-down representation of the major business processes will be decomposed into manageable functions and sub-functions until no further breakdown is possible. When combined with the detailed set of Business Requirements and the supporting Logical Data Model, this Process Model should completely address not only the full list of business needs to be satisfied by the new system, but also the vision for how the new system will provide and support this functionality.
Prototyping is a technique for providing a reduced functionality or a limited performance version of a software system early in its development (Balzer 1983, Budde 1984, Hekmatpour 1987). In contrast to the classic system life cycle, prototyping is an approach whereby more emphasis, activity, and processing are directed to the early stages of software development (requirements analysis and functional specification). In turn, prototyping can more directly accommodate early 10 user participation in determining, shaping, or evaluating emerging system functionality.
Therefore, these up-front concentrations of effort, together with the use of prototyping technologies, seeks to trade-off or otherwise reduce downstream software design activities and iterations, as well as simplify the software implementation effort. (see Rapid Prototyping)
Software prototypes come in different forms including throwaway prototypes, mock-ups, demonstration systems, quick-and-dirty prototypes, and incremental evolutionary prototypes
(Hekmatpour 1987). Increasing functionality and subsequent evolvability is what distinguishes the prototype forms on this list.
Prototyping technologies usually take some form of software functional specifications as their starting point or input, which in turn is simulated, analyzed, or directly executed. These technologies can allow developers to rapidly construct early or primitive versions of software systems that users can evaluate. User evaluations can then be incorporated as feedback to refine the emerging system specifications and designs. Further, depending on the prototyping technology, the complete working system can be developed through a continual revising/refining the input specifications. This has the advantage of always providing a working version of the emerging system, while redefining software design and testing activities to input specification refinement and execution. Alternatively, other prototyping approaches are best suited for developing throwaway or demonstration systems, or for building prototypes by reusing part/all of some existing software systems.
During the Determine Business Requirements process, a picture of the current business processes and practices will begin to evolve. This can be a useful tool in confirming that all current processes have been identified, and can be used by the Project Team as a means of ensuring that their Process Model has not neglected any existing functionality. There is a risk, however, that too much focus on current business processes may cause Customers to take a myopic view of the their true business needs, ultimately defining a system that provides little value over the system that is already in place. In summary, successful projects are inevitably built on a well-executed requirements gathering process in the system
References:
http://en.wikipedia.org/wiki/Functional_requirement
http://www.oft.state.ny.us/pmmp/guidebook2/systemreq.pdf
http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF
http://www.ics.uci.edu/~wscacchi/Papers/SE-Encyc/Process-Models-SE-Encyc.pdf
It should come as no surprise that effective requirements gathering involves much more than asking business users what they want and need. It is a complex process that involves users and system designers in a collaborative effort that explores both functional requirements and the new possibilities that technology offers.
On the part of Peter Pedro, he says that he would feel much more comfortable if we first started with a list of our requirements. They should spend some time up-front determining exactly what we want the system to do for my department. Then they systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system. In his point of view, listing requirement would satisfies the need of the company and spend time on determining what system can help to the department. But for me, it is spend time to nothing and wasting of money.
With this scenario I will go to the part of John Juan because an effective requirements gathering process is perhaps the most critical driver of software project success. The analysis begins with a review of the categories of information process. With this System Requirements Analysis can be a challenging phase, because all of the major Customers and their interests are brought into the process of determining requirements. The quality of the final product is highly dependent on the effectiveness of the requirements identification process. Since the requirements form the basis for all future work on the project, from design and development to testing and documentation, it is of the utmost importance that the Project Team creates a complete and accurate representation of all requirements that the system must accommodate. Accurately identified requirements result from effective communication and collaboration among all members of the Project Team, and provide the best chance of creating a system that fully satisfies the needs of the Customers. The primary goal of this phase is to create a detailed Functional Specification defining the full set of system capabilities to be implemented, along with accompanying data and process models illustrating the information to be managed and the processes to be supported by the new system. The Functional Specification will evolve throughout this phase of the SDLC as detailed business requirements are captured, and as supporting process and data models are created, ensuring that the eventual solution provides the Customers with the functionality they need to meet their stated business objectives.
Functional requirements also help to obtain a successful project. It may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describing all the cases where the system uses the functional requirements are captured in use cases. Functional requirements are supported by non-functional requirements (also known as quality requirements), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). How a system implements functional requirements is detailed in the system design. On the other hand a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.
Some Run-time non-functional requirements arise from the operating environment, the user(s), and competitive products:
System Constraints. Here one is looking for elements of the environment into which the system must fit, that may serve as constraints on the system. This may be true of the installed infrastructure (e.g., hardware and OS platforms) or legacy applications, or may be in the form of organizational factors or the process that the system will support.
User Objectives, Values and Concerns. In establishing the run-time qualities for a system, it is important to identify all the categories of user (including other systems) that will interact with the system, and understand what quality attributes they care about. A quality attribute such as performance may surface for one user as a concern, and another as a value, so it is useful to direct elicitation of both values and concerns for any (group of) user(s). It is important to focus on creating just what users want, with the qualities they care about—low priority whiz-bang features or qualities only increase complexity for the development organization and/or for the user. The requirements team should nonetheless be alert to requirements that users take for granted or are not able to articulate directly. Understanding the users’ objectives and forces that impact their success and sense of utility, will help surface and establish the priorities of system qualities— as well as functionality, of course.
There a lot of method helpful on the system. In the purpose of this system requirements analysis, it provides a sound basis for a specification of the system architecture, an architecture that will both satisfy immediate requirements and will be scalable and expandable to accommodate future needs.
In the purpose of Defining a Process Model is to create a pictorial representation of the functions and operations (i.e.,the processes) that will eventually be performed by the system being developed. Define the Process Model may begin at any time after the Project Team has started collecting specific business requirements. The resulting Process Model of the system, also often referred to as the “To Be” model, illustrates the system processes as they are envisioned for the new system. Over time, this pictorial top-down representation of the major business processes will be decomposed into manageable functions and sub-functions until no further breakdown is possible. When combined with the detailed set of Business Requirements and the supporting Logical Data Model, this Process Model should completely address not only the full list of business needs to be satisfied by the new system, but also the vision for how the new system will provide and support this functionality.
Prototyping is a technique for providing a reduced functionality or a limited performance version of a software system early in its development (Balzer 1983, Budde 1984, Hekmatpour 1987). In contrast to the classic system life cycle, prototyping is an approach whereby more emphasis, activity, and processing are directed to the early stages of software development (requirements analysis and functional specification). In turn, prototyping can more directly accommodate early 10 user participation in determining, shaping, or evaluating emerging system functionality.
Therefore, these up-front concentrations of effort, together with the use of prototyping technologies, seeks to trade-off or otherwise reduce downstream software design activities and iterations, as well as simplify the software implementation effort. (see Rapid Prototyping)
Software prototypes come in different forms including throwaway prototypes, mock-ups, demonstration systems, quick-and-dirty prototypes, and incremental evolutionary prototypes
(Hekmatpour 1987). Increasing functionality and subsequent evolvability is what distinguishes the prototype forms on this list.
Prototyping technologies usually take some form of software functional specifications as their starting point or input, which in turn is simulated, analyzed, or directly executed. These technologies can allow developers to rapidly construct early or primitive versions of software systems that users can evaluate. User evaluations can then be incorporated as feedback to refine the emerging system specifications and designs. Further, depending on the prototyping technology, the complete working system can be developed through a continual revising/refining the input specifications. This has the advantage of always providing a working version of the emerging system, while redefining software design and testing activities to input specification refinement and execution. Alternatively, other prototyping approaches are best suited for developing throwaway or demonstration systems, or for building prototypes by reusing part/all of some existing software systems.
During the Determine Business Requirements process, a picture of the current business processes and practices will begin to evolve. This can be a useful tool in confirming that all current processes have been identified, and can be used by the Project Team as a means of ensuring that their Process Model has not neglected any existing functionality. There is a risk, however, that too much focus on current business processes may cause Customers to take a myopic view of the their true business needs, ultimately defining a system that provides little value over the system that is already in place. In summary, successful projects are inevitably built on a well-executed requirements gathering process in the system
References:
http://en.wikipedia.org/wiki/Functional_requirement
http://www.oft.state.ny.us/pmmp/guidebook2/systemreq.pdf
http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF
http://www.ics.uci.edu/~wscacchi/Papers/SE-Encyc/Process-Models-SE-Encyc.pdf
