- Requirements Management & Engineering Methodology
- Writing Requirements
- Mastering the Requirements Process
- Requirements Modeling
Requirements Management & Engineering Methodology
In cooperation with HOOD, Please visit: www.HOOD-Group.com
Methodology
POSSIBLE ATTENDEES:
- Project manager
- Development engineers
- System engineers
- Marketing people
- Contracts officers
- Departmental managers
- QA Managers
CONTENTS SUMMARY:
Increasing complexity of the systems to be developed and higher requirements concerning costs, quality and development time mean we have to find att the possible improvement potential in the development process. This equally applies to software and hardware development projects (mechanics, electronics, equipment construction etc.). In order to get higher quality products, clients demand higher quality development processes (ISO 9000, Capability Maturity Model CMM etc.). This two-day Requirements Management course takes a tool-independent approach to understanding the key role of requirements in the context of the system development process. This course uses an interactive format, encouraging attendees to examine their existing methods of doing business and to investigate more effective approaches. The role of requirements is examined across the entire systems lifecycle, from techniques for their initial gathering through the separation of requirements from non-requirements to the relationship between requirements and other project data. Distinctions are made between "user requirements" and "system requirements" and between "functional requirements" and "non-functional requirements". Methods are discussed for organising each logically. The course considers the importance of requirements in the entire development process from both customer and supplier points of view. Attendees learn how to understand and manage iteration and the impact of change.
LANGUAGES:
This course is taught in SPANISH, whereas all the documentation given with the course will be in ENGLISH
DURATION:
2 days.
POSSIBLE ATTENDEES:
- Project managers
- Development engineers
- System engineers
- Marketing people
- Sales personnel
- Departmental managers
- QA Managers
- Everybody who has to write requirements
CONTENTS SUMMARY:
Language is the preferred method of communication and will always be first choice when expressing user requirements, regardless of different methods in systems or software engineering and field of business. An interview between user/customer and analyst is the main source of requirements for a new project. This conversation often brings people from totally different backgrounds together. Expressing requirements in natural language can bridge the gap between them. The use of natural language requirements as the foundation of product development implies the observance of certain rules. This training provides some techniques for the successful elicitation of requirements and the following questions are answered:
- Where do requirements come from?
- How do I describe requirements?
- How do I manage requirements?
- Which templates can I use to gather requirements?
- Which different kinds of requirements are there?
In complying with the learnt approach the daily work in your organization profits by the following means:
- Improved clarity and effectiveness in your requirements
- Increased ease in implementing requirements
- Better management of complex development efforts, as more personnel have a clearer understanding of requirements
- Stricter adherence to standards
- Improved product quality
- Shortened product development times and reduced development costs
LANGUAGES:
This course is taught in SPANISH, whereas all the documentation given with the course will be in ENGLISH
DURATION:
1 day.
In cooperation with HOOD, Please visit: www.HOOD-Group.com
Mastering the Requirements Process
This seminar will give you:
- A process for gathering the correct requirements.
- Methods of eliciting requirements from all the stakeholders.
- Ways of knowing when your solution precisely matches what the user needs.
- The ability to write a compete and unambiguous requirements specification.
- Improved relationships with your software customers.
Is the next system you build one that the users will look back after years of happy use and thank you for... or will you look back after years of heavy maintenance and wonder why it happened to you?.
Why Requirements – What's in it for You?
People use software, but other people build that software. There's the problem. Solving it means understanding the actual work of the business users, and what they need in order to do it. It does not mean finding a quick fix for a perceived problem. It does mean deducing the product that adds long-term value to the organization, and then writing requirements that lock the developers in to that exact product. Any omissions or ambiguities mean going back to step one.
Getting it Right the First Time
The days of building software in "Internet time" are over. Building software today means that you are in it for the long haul. And you know that there are more demands than ever, and fewer resources to meet those demands. Getting the software right – the first time – is the only way to succeed under these circumstances. Today's requirements process is incremental with quick cycle times. It uses prototypes and scenarios, and it ensures that you get the right result by writing a fit criterion – a test case for the requirement.
Your Requirements
Requirements are the most misunderstood part of systems development, but also the most crucial. Get the requirements wrong and you get the wrong system. Your requirements process must be your own, but it should be based on field-proven techniques and templates. In this course, you are shown the Volere process – used and improved by thousands of organizations around the world – and how you make it your ownprocess. You also receive the Volere Requirements Specification Template – downloaded by over 13,000 users – to take home with you along with advice on how to make this your own template.
Is This for Me?
This seminar has indispensable information for business analysts, systems mangers , project leaders , consultants and systems analysts and planners . This material applies to all stakeholders: users and customers will benefit from learning how to participate in this multi-disciplinary approach. It is for anybody who has a responsibility to deliver the right products - the ones that get used.
What Will I learn? What Will I be Better at?
• The Requirements Process
This section introduces you to the Volere process – a solid strategy for gathering the correct requirements. In this overview session you see how the pieces fit together – from the project blastoff that established the product's purpose and scope, the trawling and prototyping activities that elicit the product's requirements, through the Quality Gateway where requirements are made testable, to the final review of the specification that discovers any missing requirements.
• Project Blastoff
This activity lays the foundation for the requirements project by establishing the Scope-Goals-Stakeholder trilogy. This initiation activity establishes the precise scope of the work to be studied, determines a testable goal for the project, and uses stakeholder maps to identify all the sources of requirements. In short, the blastoff ensures that the project is viable and worthwhile.
• Trawling for Requirements
At the core of any requirements process is the ability to get people to tell you what they really need, rather than what they think you might be able to deliver, or what they feel their boss might want. We show you how to apply business use cases, use case workshops, interviewing and other strategies to discover exactly what the users need, and want.
• Functional Requirements
Functional requirements are those things that the product must do. They are discovered by inspecting the work that the user does, and then determining what part of that work the automated product can do. This proposed interaction between user and product is modeled with use case scenarios. From these, we derive and write the functional requirements.
• Non-functional Requirements
Non-functional requirements are those properties that the product must have, such as the desired look and feel, the usability, the performance and its cultural aspects. This section discusses the types of non-functional requirements, and shows you how to use the template, and other methods, to find the qualitative requirements for your product.
• Managing Your Requirements
Requirements are the lynchpin of any development effort, and as such have to be written correctly and managed effectively. This section demonstrates the use of a template and other devices to help you write requirements. It also looks at requirements management issues like traceability, prioritization and conflictng requirements. We also include a review of most of the automated tools that are available to help manage requirements specifications.
"For the first time, modeling appears to me to be a tool, not a burden." – Lew Mullen, Schlumberger
This seminar will show you :
- How to use requirements models to prove the required functionality
- How to elicit requirements using models
- How to add rigor to your requirements
- How to use understand your customer's requirements using models
Requirements modeling and you
Requirements models are used when gathering requirements, and during systems analysis. Whether you consider eliciting requirements to be a separate activity, or a part of systems analysis, the importance of correct requirements must be a high priority for you. Building accurate models means that you can guarantee the correctness of your requirements.
All engineering disciplines use models to develop the products they intend to build. In our industry we use requirements models to discover and clarify the functional and data requirements for software and business systems. Additionally, the models are used as specifications for the designers and builders of the system.
What a system is and what does a system do
You can describe a system by what it is, and by what it does. For an example of what it does, consider this typical statement from a requirements specification: "The product must calculate the cheapest fare". Beyond this innocent description of what the system must do, lies a significant set of rules, procedures, data and functions. It is the task of requirements modeling to discover the rules for calculating the cheapest fare, the algorithms needed, and the data needed to support those calculations. In this way the requirements models describe what the system is.
You also use models when eliciting requirements. A quickly sketched data flow model is an indispensable aid during interviews. A data model reveals the policy of the system. Thus a data model constructed with your customer quickly reveals any gaps in the policy. A state model can explain how a system behaves, and thus clarifies for a potential user the consequence of the requirements.
This seminar shows you how to use the requirements models to elicit requirements, and how to prove the correctness of those requirements. Workshops during the seminar give you the practical skills to put these models to work for you right away.
This seminar is a companion to Mastering the Requirements Process . It teaches you the various models available to the modern requirements engineer and systems analyst. It gives you the tools to improve your skills, and to improve the way you build your systems specifications.
Is this for me?
By bridging the gap between the requirements gathering and systems analysis, this seminar brings you an intensive tour of the available requirements models, and most importantly, how you can make the best use of use them.
You should attend if you are a:gt;
- Business analyst
- Requirements engineer
- Systems analyst
- Systems manager
- Project leader
- Consultant
What will I learn in two days?
Requirements Models
This introduces the craft of modeling requirements. We look at how models can be used when dealing with the client, and how to prove the correctness of the functionality and data once the requirements are known.
The Context
To get the right scope for the product, start with the work where the product is to be deployed. The context model shows the work area and how it relates to the adjacent systems. From this you determine the scope of the product you intend to build.
Business Event Partitioning
How to use business events – important happenings in the outside world – to break the work into manageable and convenient pieces. These pieces later become the product's use cases.
Process Modeling
Discovering the (sometimes hidden) functionality of the system by modeling it. We look at how viewpoints are used to show different aspects of the system, and how the essence reveals the true system.
Data Modeling
By understanding what a system remembers, we understand what it does. This section introduces the idea of modeling the stored data, and shows the strong affinity between the process and the data.
State Models
State models are used when the system under study is best revealed by looking at its behavior. State models show the steady states that a system has, and how business events cause a transition between those states.
Modeling the Product
This goes beyond the requirements to look at how the product is derived from the functionality and data of the work, and how UML models are used to shape the product to be built.
Learn through practice
This seminar includes frequent exercises and opportunities to apply the illustrated techniques. Work with the instructor to build models and discover the real needs of the business. Also learn to evaluate when each of the models is useful, and what degree of detail is necessary.
Legal & Privacy Policy