Athena prides itself on a strong development process for its project and product development.  Two of the processes we use internally as well as mentor others in are Rational Unified Process and Requirements Management with Use Cases.

The Rational Unified Process product keeps your entire team focused on incrementally producing working software on time with required features and with required quality. Industry-proven best practices, contained within RUP, incorporate the lessons learned from hundreds of industry leaders, and thousands of projects.

The RUP has two dimensions as depicted in the attached graphic:

• the horizontal axis represents time and shows the lifecycle aspects of the process as it unfolds
• the vertical axis represents disciplines, which group activities logically by nature.

The first dimension represents the dynamic aspect of the process as it is enacted, and it is expressed in terms of phases, iterations, and milestones.

The second dimension represents the static aspect of the process: how it is described in terms of process components, disciplines, activities, workflows, artifacts, and roles.

The graph shows how the emphasis varies over time. For example, in early iterations, we spend more time on requirements, and in later iterations we spend more time on implementation.

Our formal definition of requirements management is that it is a systematic approach to

• eliciting, organizing, and documenting the requirements of the system, and
• establishing and maintaining agreement between the customer and the project team on the changing requirements of the system.

Keys to effective requirements management include maintaining a clear statement of the requirements, along with applicable attributes for each requirement type and traceability to other requirements and other project artifacts.

Collecting requirements may sound like a rather straightforward task. In real projects, however, you will run into difficulties because:

• Requirements are not always obvious, and can come from many sources.
• Requirements are not always easy to express clearly in words.
• There are many different types of requirements at different levels of detail.
• The number of requirements can become unmanageable if not controlled.
• Requirements are related to one another and also to other deliverables of the software engineering process.
• Requirements have unique properties or property values. For example, they are neither equally important nor equally easy to meet.
• There are many interested parties, which means requirements need to be managed by cross-functional groups of people.
• Requirements change.

We can help your organization with these important processes which will ensure your projects are delivered on time and on budget.  We can perform on-site training or provide training at one of our affiliated training locations.

Our trainers are all experts in their respective processes and provide a practitioners approach to efficient usage by leveraging real world examples in the classroom.

An example comment from a recent course review:

...[instructor name] is an excellent instructor.  He seems knowledgable from extensive experience.  He has a very good conversational style of doing lectures.  He was very good at providing individual help to class members in getting through the excercises and tailoring the class content and schedule to the pace of class members." - Hallmark Cards, Inc.