Ahmed Hassan Ghulam Murtaza Umar Farooq M Mannan Razzaq BSEF08A011 BSEF08A031 BSEF08A034 BSEF08A050.

Slides:



Advertisements
Similar presentations
May 2, May 2, 2015May 2, 2015May 2, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa, CA.
Advertisements

Chapter 10 Schedule Your Schedule. Copyright 2004 by Pearson Education, Inc. Identifying And Scheduling Tasks The schedule from the Software Development.
Systems Analysis and Design 9th Edition
Chapter 2.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Requirements Analysis INCOSE Systems Engineering Boot Camp
SE 555 Software Requirements & Specification Beyond Requirements Based on Weigers Chapter17.
Fundamentals of Information Systems, Second Edition
SE 555 Software Requirements & Specification Requirements Validation.
Pertemuan Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
LEARN. NETWORK. DISCOVER. | #QADexplore Implementing Business Process Management: Steps to Success WCUG – November 18, 2014.
Release & Deployment ITIL Version 3
Chapter : Software Process
Copyright 2003 by Ralph R. Young Desired Skills and Characteristics of an Effective Requirements Analyst Presentation for The Washington D.C. Software.
 A project is “a unique endeavor to produce a set of deliverables within clearly specified time, cost and quality constraints”
S/W Project Management
Requirements Development VIASYS Healthcare. What is a requirement? 1) A condition or a capability needed by a user to solve a problem or achieve an objective.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Chapter 2 The process Process, Methods, and Tools
Chapter 8: Systems analysis and design
Why use RequisitePro RequisitePro is a comprehensive tool that supports any of today's requirements management processes. The predominant requirements.
Project Management : Techniques and Tools (60-499) Fall 2014 / Winter 2015.
Requirement-Related Risks Extracted from the book: Software Requirements By Karl E.Wiegers.
Chapter 2 소프트웨어공학 Software Engineering 임현승 강원대학교
Teaching material for a course in Software Project Management & Software Engineering – part II.
Industrial Software Project Management Some views on project managing industrial and business software projects.
CEN rd Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Phases of Software.
Software Development Process and Management (or how to be officious and unpopular)
1 The Software Development Process  Systems analysis  Systems design  Implementation  Testing  Documentation  Evaluation  Maintenance.
1 Chapter 5 Software Engineering Practice. 2 What is “Practice”? Practice is a broad array of concepts, principles, methods, and tools that you must consider.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Coming up: Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Event Management & ITIL V3
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
IT Requirements Management Balancing Needs and Expectations.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
1 Requirements Management - General concepts - Noureddine Abbadeni King Saud University College of Computer and Information Sciences Based on “Software.
Systems Analysis and Design 8 th Edition Chapter 2 Analyzing the Business Case.
Software Engineering Saeed Akhtar The University of Lahore Lecture 6 Originally shared for: mashhoood.webs.com.
The Development of BPR Pertemuan 6 Matakuliah: M0734-Business Process Reenginering Tahun: 2010.
Systems Analysis and Design in a Changing World, Fourth Edition
Develop Project Charter
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
The Software Development Process
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
Chapter 6 CASE Tools Software Engineering Chapter 6-- CASE TOOLS
Page 1 JUSTIFY define and validate REQUIRE- MENTS define initial management DOCUMENTS define INFRA- STRUCTURE allocated maintenance changes management.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Software Engineering Lecture # 1.
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.
Requirement Engineering
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance.
1 TenStep Project Management Process ™ PM00.5 PM00.5 Project Management Preparation for Success * Manage Scope *
44222: Information Systems Development
Systems Analysis & Design 7 th Edition Chapter 2.
Requirement Engineering Management Amna Shifia Nisafani Feby Artwodini M. Department of Information Systems Subject : Requirement Engineering.
1 Advanced Computer Programming Project Management: Basics Copyright © Texas Education Agency, 2013.
Requirement Elicitation Nisa’ul Hafidhoh Teknik Informatika
CHAPTER 2 SYSTEM PLANNING DFC4013 System Analysis & Design.
Managing the Project Lifecycle
Systems Analysis and Design in a Changing World, 4th Edition
Maintaining Quality Test Optimization with Increasing Software Complexity Ankit Goyal Software Engineer II Adobe Systems.
Unit 6: Application Development
Managing Change and Quality
Joint Application Development (JAD)
Presentation transcript:

Ahmed Hassan Ghulam Murtaza Umar Farooq M Mannan Razzaq BSEF08A011 BSEF08A031 BSEF08A034 BSEF08A050

BY: Ahmed Hassan BSEF08011

Requirement Management Definition Overview The Roles of the RA Traceability Requirements activities Tools References

Requirement Management

Why Requirement Management Between 40% and 60% of software failures and defects are the result of poor software requirements management. In plain English, this means that about half of the problems encountered could have been avoided by making it clear, from the very beginning, what the customer expected from the respective project. This is to say that the programming was fine and the developers did their job well – only they did a different job from what they were supposed to.

Requirement Management Definition : “ Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome. ”

Overview The purpose of requirements management is to assure the organization documents, verifies and meets the needs and expectations of its customers and internal or external stakeholders. Requirements management begins with the analysis and elicitation of the objectives and constraints of the organization. Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project.

The Roles of the RA The RA is in a strategic position to improve the practices in use on projects and in the organization. The analyst can have a positive impact on project success and also facilitate the organization’s improvement results by performing in several roles.

BY: Umar Farooq BSEF08034

Suggested Roles of the RA 1.Work collaboratively with customers, users, and system architects and designers to identify the real requirements for a planned system or software development effort to define the problem that needs to be solved.

2.Effectively with customers and users to manage new and changed requirements so that the project stays under control. Install a mechanism to control changes. 3.Be alert to new technologies that may help. 4.Facilitate the project’s reuse of artifacts and achieving repeatability.

5. Assist the project and its customers in envisioning a growth path from the first release or version of a product through a set of staged releases to the ultimate system or product. 6. Advise the project (and customer) of methods, techniques, and automated tools that are available to best support requirements-related project work and activities.

7. Use metrics to measure, track, and control requirements-related project work activities and results. 8. Be able to facilitate discussions and to mediate conflicts. 9. Study the domain of the area in which the system or software is being used.

Traceability Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Even the use of the requirement after the implemented features have been deployed and used should be traceable.

Tracing requirements also involves additional tests, performed from time to time, to insure that the process runs smoothly and errors are identified and corrected early on. When faced with a big project, you may have different sets of requirements, some that apply to the entire project, and some for parts of it.

BY: M Mannan Razzaq BSEF08050

Requirements activities 1.Investigation 2.Feasibility 3.Design 4.Construction and test 5.Release

Investigation In Investigation, the first three classes of requirements are gathered from the users, from the business and from the development team. In each area, similar questions are asked; what are the goals, what are the constraints, what are the current tools or processes in place, and so on. Only when these requirements are well understood can functional requirements be developed.

The deliverable from the Investigation stage is a requirements document that has been approved by all members of the team. Later, in the thick of development, this document will be critical in preventing scope creep or unnecessary changes. As the system develops, each new feature opens a world of new possibilities, so the requirements specification anchors the team to the original vision and permits a controlled discussion of scope change. Continue…..

Feasibility In the Feasibility stage, costs of the requirements are determined. For user requirements, the current cost of work is compared to the future projected costs once the new system is in place. Questions such as these are asked: “What are data entry errors costing us now?” Or “What is the cost of scrap due to operator error with the current interface?” Actually, the need for the new tool is often recognized as these questions come to the attention of financial people in the organization.

Business costs would include, “What department has the budget for this?” “What is the expected rate of return on the new product in the marketplace?”

Technical costs are related to software development costs and hardware costs. “Do we have the right people to create the tool?” “Do we need new equipment to support expanded software roles?” This last question is an important type. The team must inquire into whether the newest automated tools will add sufficient processing power to shift some of the burden from the user to the system in order to save people time.

BY: Ghulam Murtaza BSEF08031

Design Assuming that costs are accurately determined and benefits to be gained are sufficiently large, the project can proceed to the Design stage. In Design, the main requirements management activity is comparing the results of the design against the requirements document to make sure that work is staying in scope.

Construction and test In the construction and testing stage, the main activity of requirements management is to make sure that work and cost stay within schedule and budget, and that the emerging tool does in fact meet requirements. A main tool used in this stage is prototype construction and iterative testing. For a software application, the user interface can be created on paper and tested with potential users while the framework of the software is being built. Results of these tests are recorded in a user interface design guide and handed off to the design team when they are ready to develop the interface. This saves their time and makes their jobs much easier.

Release Requirements management does not end with product release. From that point on, the data coming in about the application’s acceptability is gathered and fed into the Investigation phase of the next generation or release. Thus the process begins again.

Tools

There exist many tools for requirements management. Like rmtoo, accompa, Rational RequisitePro etc.

Requirement Management tools help project teams to manage their requirements, to write good use cases, to strengthen collaboration, to reduce project rework, and to increase quality.

Reasons to Use Requirements Management Tools: Structured Requirements: Requirements management tools enable you to gather “structured” requirements.

Save Time: Good requirements management tools can save you a ton of time when it comes to managing your requirements Easy to Collaborate: A good requirements management tool will enable you to collaborate with your internal and external stakeholders efficiently & effectively.

Workflow & Best Practices: Good requirements management software tools have built-in workflow and best practices for a lot of tasks related to requirements management. This will help you make your products and projects more successful.

Things to Look for When Considering Requirements Management Tools Ease-of-Use “Avoid tools that are too complex…”. If requirements management tools are too complex, your users simply won’t use it - no matter how powerful the tools are. After all, none of us come to work wishing our lives were more complex!

Total Cost: Cost is always an issue with any purchase, and RM tools are no exception. Make sure to consider the “Total Cost” Matches Your Needs Today: Select an RM tool that matches your requirements needs today, and will grow with you. There is often a temptation to pick an RM tool with the largest feature set. Avoid this temptation

Try Before You Choose: These days, many requirements management tool vendors (such as Accompa) allow you to test drive their software for free, before you buy. Take advantage of it. After all, you won’t truly know whether an RM tool can help you until you try it out in real-life scenarios.such as Accompa

References The Requirement Engineering Handbook ctivities d_test