Unit 1 Requirement Analysis

Unit 1 Software Project Management

Software project management is the art and science of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, monitored and controlled. Activities covered by software project management:

Feasibility Study

How do we do it?

What Is a Requirement? Although many definitions of software requirements have been used throughout the years, the one provided by requirements engineering authors Dorfman and Thayer (1990) is quite workable:
o o

A software capability needed by the user to solve a problem to achieve an objective A software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation

Requirements Management
Software Project Management Page 1

Is i t h wort ? doing


Do it!

Project execution

The feasibility study/plan/execution cycle

related to identified business needs or opportunities. the scale of our work continues to grow. a few individuals could hand craft small programs. the work soon grew beyond them. If we build a system that conforms to those requirements. and defined to a level of detail sufficient for system design. Initially. Requirements management includes organizing. Requirements analysis Requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product. organizing. and non-functional. Today. behavioural. correctly. structural. and documenting the requirements of the system. and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system. We'll represent them as a block within our pyramid in a similar manner to the features. taking account of the possibly conflicting requirements of the various stakeholders. and providing resources for the various requirements. Teams of one or two dozen individuals were then used. We also note that these appear pretty far down on the pyramid. since the features address one or more stakeholder needs. controlling access to. such as beneficiaries or users. that we have much work to do before we get to that level of specificity later in the book. Software Requirements Once we have established the feature set and have gained agreement with the customer. large projects typically require the coordinated work of many teams. we will have addressed those needs directly in the solution. we can move on to defining the more specific requirements that we will need to impose on the solution. These more specific requirements are the software requirements. Requirements can be architectural.Unit 1 Requirement Analysis Requirement management is a systematic approach to eliciting. Requirements analysis is critical to the success of a development project. testable. Software Project Management Page 2 . While many organizations have solved these small-system problems. The Software Team The history of software development is one of increasing scale. we can be certain that the system we develop will deliver the features we promised. In turn. prioritizing. Requirements must be documented. but success was mixed. measurable. functional. actionable. and this implies.

and the domains in which we apply our skills vary tremendously. and we show how traceability can be used to help ensure a quality outcome. we develop a set of techniques the team can use to gain a proper understanding of the problem that a new software system is intended to solve. we introduce a set of techniques the team can use to elaborate on the system definition. 5) Refining the System Definition. Further. we help the team organize the requirements information. or refine it to a level suitable to drive design and implementation. so that the entire extended team knows exactly what kind of system it is building. we describe the initial process by which the team converts an understanding of the problem and the user's needs to the initial definition of a system that will address those needs. and change management.Unit 1 Requirement Analysis Requisite Team Skills for Effective Requirements Management 1) Analyzing the Problem. It therefore seems unlikely that one specific way to organize a software team will work in all cases or is inherently more efficient than other approaches. 4) Managing Scope. 3) Defining the System. 2) Understanding User Needs. we introduce a variety of techniques the team can use to elicit requirements from the system users and stakeholders. The team we'll model is based on a real-world software team that has proved effective in two major areas: (1) Effective requirements management Software Project Management Page 3 . validation testing. we think it's important to establish a hypothetical team construct. Nonetheless. certain common elements occur in many successful teams. 6) Building the Right System. we arm the team with the ability to do a better job of managing the scope of the project. verification. we cover some of the more technical aspects of design assurance. But rather than invent an ideal team. which would be too easy and too academic. The Organization of Software Teams Software development is exceedingly complex. Therefore. we decided to pattern our hypothetical team on a real software development team.

5) Identify the constraints to be imposed on the solution. Five Steps in Problem Analysis 1) Gain agreement on the problem definition. that an incremental investment in an analysis of the problem will produce handsome rewards downstream. the data demonstrates that we remain challenged in our ability to truly understand and to satisfy these needs. 4) Define the solution system boundary. The goal of this team skill is to provide guidelines for problem analysis and to define specific goals for this skill in application development. it should now be easier than ever before to develop systems that satisfy real business needs. therefore. and career challenges. dissatisfied users. 3) Identify the stakeholders and the users. we believe that this is an obvious causeand-effect relationship!) Analyzing the Problem The last few years have seen an unprecedented increase in the power of the tools and technologies that software developers use to build today's enterprise applications. It seems obvious. The consequences of this mismatch are inadequate economic reward for the customers and developers of the system. As the productivity of the software development environment has increased. However.Unit 1 Requirement Analysis (2) Delivering on time and on budget. Understand the Root Causes—the Problem behind the Problem Software Project Management Page 4 . 2) Understand the root causes—the problem behind the problem. The resulting systems do not fit the needs of the users and stakeholders as well as could have been reasonably expected. Gain Agreement on the Problem Definition The first step is to gain agreement on the definition of the problem to be solved. (Of course. One of the simplest ways to gain this agreement is to simply write the problem down and see whether everyone agrees.

There are certain methods for identifying the problem behind the problem. the materiality. The results of this investigation can be plotted as a Pareto chart. or underlying. Pareto chart of root causes Identify the Stakeholders and the Users Software Project Management Page 5 . of each root cause is determined. cause of an identified problem or a symptom of a problem. or contribution.Unit 1 Requirement Analysis There are variety of techniques to gain an understanding of the real problem and its real causes. One such technique is "root cause" analysis. They are • • Fishbone diagram Pareto analysis Fishbone diagram of root causes In fish bone diagram method each source was listed as one of the "bones" on the diagram. which is a systematic way of uncovering the root. Once the root causes are listed on the "bones" of the diagram.

Information. is passed back and forth from the system to the users living outside the system. All interactions with the system occur via interfaces between the system and the external world. we enter an important transition state wherein we have to keep two things in mind: an understanding of the problem and the considerations of a potential solution. The next important step is to determine the boundaries of the solution system. System boundary Identify the Constraints to Be Imposed on the Solution Before launching a well-intended trillion-dollar effort to revolutionize the state of the art in sales order entry. Each constraint has the potential to severely restrict our ability to deliver a solution as we envision it. Define the Solution System Boundary Once the problem statement is agreed to and the users and stakeholders are identified. we must stop and consider the constraints that will be imposed on the solution. in the form of inputs and outputs. In other words. Therefore. The system boundary defines the border between the solution and the real world that surrounds the solution. In so doing. the system boundary describes an envelope in which the solution system is contained. we can turn our attention to defining a system that can be deployed to address the problem.Unit 1 Requirement Analysis Effectively solving any complex problem typically involves satisfying the needs of a diverse group of stakeholders. We'll define a constraint as a restriction on the degree of freedom we have in providing a solution. Stakeholders will typically have varying perspectives on the problem and various needs that must be addressed by the solution. each constraint must be carefully considered Software Project Management Page 6 .

Systems engineering(SE) Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed. A variety of sources of constraints must be considered. and automatic control of machinery become more difficult when dealing with large. and project management. databases. documenting requirements. It focuses on defining customer needs and required functionality early in the development cycle. operating systems. complex projects. environmental issues. organizational studies. then proceeding with design synthesis and system validation while considering the complete problem: Operations • Performance • Test • Manufacturing • Cost and Schedule • Training and Support • Disposal Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to Software Project Management Page 7 . and many may even cause us to reconsider the technological approach we have initially envisioned. These constraints may be given to us before we even begin ("No new hardware"). Issues such as logistics. purchased software. and it overlaps with both technical and human-centered disciplines such as control engineering. These include schedule. budget for labour and equipment. or we may have to actively elicit them. and a host of other considerations. the coordination of different teams. choices of tools and languages. company policies and procedures. Systems engineering deals with work-processes and tools to handle such projects. hosts and client systems. return on investment. technical issues. personnel or other resource constraints. industrial engineering.Unit 1 Requirement Analysis as part of the planning process. (International Council on engineering system – INCOSE 1999) Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. political issues within the organization.

to identify and improve common rules that exist within a wide variety of systems. tools are used for various stages of the systems engineering process: Software Project Management Page 8 . or practice. Scope of Systems engineering One way to understand the motivation behind systems engineering is to see it as a method. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the needs of the user. Systems engineering encourages the use of modelling and simulation to validate assumptions or theories on systems and the interactions within them.Unit 1 Requirement Analysis operation. The systems engineering process Depending on their application.

8) Manage against a plan. 7) Use an articulated and documented process. 3) Establish and manage requirements. know the customer. should provide us with the steps we need to apply to use systems engineering to analyze the problem in our requirements context. the specific steps. The INCOSE Systems Engineering Practices working group (INCOSE 1993) defined a basic set of eight systems engineering principles. 4) Identify and assess alternatives so as to converge on a solution. 5) Verify and validate requirements and solution performance. 2) Use effectiveness criteria based on needs to make the system decisions. 6) Maintain the integrity of the system.Unit 1 Requirement Analysis Pragmatic Principles of Systems Engineering: If we choose to view systems engineering as a problem analysis technique. Software Project Management Page 9 . or at least the basic principles of the discipline. and know the consumer. 1) Know the problem.

or A conceptual. however. • • • An abstraction of reality designed to answer specific questions about the real world An imitation. In point of fact. Software Project Management Page 10 . mathematical. analogue.Unit 1 Requirement Analysis This list identifies some pragmatic systems engineering principles. or representation of a real world process or structure. the successive decomposition of complex systems into simpler ones. a subset of the systems engineering discipline is based on another process. including. A model can be defined in several ways. or physical tool to assist a decision maker. Using models Models play important and diverse roles in systems engineering.