Expand +



Would You Build a House Without a Blueprint? Managing the Requirements and Design Phases of Your Application Projects

by Kishore Bhamidipati | SAPinsider

October 1, 2010

Dive into the first two phases of the application lifecycle management process—Requirements and Design—and find out how the SAP Enterprise Modeling application by IDS Scheer helps organizations navigate through each of them. This article also outlines the tool’s role and benefits in two specific SAP scenarios.

Application lifecycle management (ALM) is a popular phrase among developers, administrators, system architects, and IT system operators these days, since IT systems are becoming more complex and heterogeneous, and development efforts are touching various points in the landscape.

In a previous SAPinsider article1, I provided a holistic overview of ALM and discussed the role it plays in helping the business of IT run more smoothly. I also touched on the six phases of an application’s life cycle and discussed the solution extensions offered by SAP that are targeted to ALM.

In this article, I will dive deeper into the first two ALM phases — Requirements and Design — and uncover how the SAP Enterprise Modeling application by IDS Scheer helps organizations address the challenges that each of these phases presents. I’ll also take you through the tool’s role and benefits in two specific scenarios: developing new SAP applications and upgrading existing implementations.

Beginning the ALM Cycle: Requirements and Design

As I noted in my previous article, application lifecycle management is divided into six phases, based on the IT Infrastructure Library (ITIL) standard: Requirements, Design, Build and Test, Deploy, Operate, and Optimize (see Figure 1).

Figure 1 An overview of the six ITIL phases of ALM; this article focuses on the Requirements and Design phases

Let’s look more closely at the first two phases.

Gather and Document Business Needs in the Requirements Phase

During this phase, business analysts define the needs and requirements2 for a project, a process that includes:

  • Requirements analysis, which is critical to a development project’s success, refers to the tasks involved in determining the needs or conditions for a new or altered product, while taking into account the (sometimes conflicting) requirements of stakeholders, including end users. Requirements must be documented, actionable, measurable, testable, related to identified business needs or opportunities, and sufficiently defined for system design.
  • Requirements management involves identifying, eliciting, documenting, analyzing, tracing, prioritizing, and agreeing on requirements. It also includes monitoring changes and communicating them to relevant stakeholders. Requirements management is a continuous process throughout the life of a project.

Blueprint and Model in the Design Phase

In the Design phase, which is closely linked to the Requirements phase, business analysts create a blueprint for the application or solution by selecting processes and scenarios to implement. Software design is a process of understanding the problem that the final solution should solve and ensuring that the software can in fact address the problem when it is ready. After the purpose and specifications of software are determined, software developers usually design a plan for a solution. The plan includes low-level component and algorithm implementation issues, as well as the architectural view.

Many different tools are used during the Design phase, including modeling tools or modeling languages, such as business process modeling notation (BPMN) and Unified Modeling Language (UML).3

Finding the Right Tools to Support Requirements and Design: Easier Said Than Done

The Requirements and Design phases are perhaps the most important phases of the full application life cycle. You’d be hard-pressed to complete a successful application project without doing this upfront work. I equate it to custom-building a house; a contractor can’t just start buying concrete and sheetrock without asking the homeowners what they want the house to look like. Nor can he just start hammering and nailing things together without a detailed blueprint and schedule to follow.

But executing the Requirements and Design phases isn’t easy. You have to keep track of needs and specifications from various stakeholders. Plus, written requirements often get lost in translation between business and IT. Companies would be well-served to find a solution to help with this process; one such solution is SAP Enterprise Modeling by IDS Scheer.

SAP Enterprise Modeling offers a combination of modeling, design, and process performance management functionality that moves beyond conceptual business process analysis toward the planning and governance of corporate business architecture.4 This web-based, role-based, intuitive solution, which both the business and IT sides can use and collaborate around, assists with enterprise modeling while also allowing you to simulate how processes may be affected when new applications are added or software is upgraded.

With this tool, you can structure, identify, and describe the mission-critical IT components within your infrastructure and align them to the requirements of each business process. And, with the integrated modeling environment, you can design business processes based on consistent standards throughout the enterprise and implement internal controls throughout your IT architecture to comply with regulations and support your IT gover­nance initiatives. The tool also supports planning processes, from documenting and analyzing the existing IT architecture to establishing a whole new architecture (see sidebar for additional benefits).

You can also reduce the complexity and duration of business intelligence consolidation projects by modeling, integrating, and aligning views and data flows from SAP NetWeaver Business Warehouse (SAP NetWeaver BW). This makes it easier to apply analytical information to your business processes and provide valuable insight to your employees as they execute day-to-day activities.

SAP Enterprise Modeling: 2 ALM Use Cases

Now, let’s look at how organizations can use SAP Enterprise Modeling in two ALM scenarios.

Scenario #1: Developing New SAP Applications

Imagine that the product development team at a retail company wants to create a new online bookstore to sell collateral. For the implementation of this new application, the business team would need to determine — and communicate to IT — the features they would like to include on the website, such as the categories in which books are listed, the type of shopping cart, and search capabilities. This new application would need to connect to the organization’s ERP back end to incorporate financial information, as well as to a database to store customer information.

When developing the requirements for this implementation, business analysts would ideally look at all possible scenarios and talk with other stakeholders on the business side to consider everyone’s requirements. They should look at the big-picture goals of the project, including goals from the end user’s perspective (in our example, the end user is the customer browsing the online store), and break the requirements down into subtasks. It is advisable to do as much planning as possible during this phase to avoid delaying or derailing the development by drastically changing requirements later. Business analysts often discuss, gather, and document requirements using email, spreadsheets, and Microsoft Word documents. And too often there is a disconnect between business and IT after the requirements are handed off to the developers — that is, business and IT may not understand what the other side wants.

To address this challenge, SAP Enterprise Modeling enables business analysts to draw a diagram illustrating their requirements and vision for the end product. With this tool, they can create a visual representation (a block diagram) of their requirements — in essence, designing and modeling the flow of an application as they gather requirements, resulting in less confusion, ambiguity, and misinterpretation (see Figure 2).

Figure 2 SAP Enterprise Modeling combines business and IT information on the same screen

SAP Enterprise Modeling also allows business folks and IT to collaborate around the same visual diagram (a flow chart, for example) during the Design phase (see Figure 3). It supports modeling methods, such as event-driven process chains (EPCs) and languages such as BPMN and UML, which both business and IT can understand. Plus, the models can be stored in a central repository, enabling users to easily access the most up-to-date version. IT can then work from this diagram when developing the code for the new application.

Figure 3 A flow chart of a business process

As business analysts design and model a new application with SAP Enterprise Modeling, they can work across both SAP and non-SAP platforms and systems and synchronize business processes that span different environments (such as finance and sales). In our scenario, for example, the business analysts can look at the model of the new online store from a customer relationship management (CRM) view and a financials view. The tool also contains functionality for administering databases, users, reports, and scripts. For example, teams can connect to existing databases, and multiple users can interact and use the same platform. In addition, users can generate reports on the status of the project or of the model itself, and they can keep records of relevant project communications between business and IT.

Scenario #2: Upgrading Existing SAP Implementations

SAP Enterprise Modeling can also help you optimize and standardize business processes as you upgrade the software that drives your business. Imagine that you are a supply chain manager, and your company has upgraded its SAP ERP system to the latest version. You would need to consider the new functionality that the upgrade is introducing and determine how it affects your existing business processes. For example, you may find that functionality in the upgrade automatically verifies values in a certain field, whereas this step was previously done manually. Thus, you can eliminate this step from the business process.

Most importantly, you also want to ensure that your relevant business processes are integrated and standardized. To make sure that these business processes are integrated into the upgraded implementation and that you don’t lose functionality or compromise your business process performance as a result of the upgrade, SAP Enterprise Modeling offers functionality and interfaces for process-driven SAP software management; the tool also takes advantage of the standard SAP process scenario, which can describe both existing “as-is” processes and future “to-be” processes. With SAP Enterprise Modeling, you can get a high-level view of the key processes, and then drill down. This allows you to easily move from a conceptual level to a logical or even a physical level, all while maintaining appropriate relationships and threads across these levels.

SAP Enterprise Modeling also allows you to navigate to SAP transactions, access documentation of business scenarios and processes, and run queries to see how a particular process would be affected by an upgrade (see Figure 4). The tool enables you to model business process execution language (BPEL) processes in an early stage so that you can then import them into SAP NetWeaver Process Integration (SAP NetWeaver PI) for enhancing, configuring, and executing. Finally, SAP Enterprise Modeling allows you to visualize data structures and data flows in your new SAP implementation (see Figure 5).

Figure 4 A business blueprint showing process changes
Figure 5 You can visualize data structures and data flows in a new SAP implementation

Learn More

Clearly you can’t ignore the Requirements and Design phases of ALM; these are integral steps to any development project. But you don’t have to dive into these phases without support — SAP Enterprise Modeling by IDS Scheer can help you more efficiently develop new SAP applications and upgrade your existing SAP implementations.

To learn more, visit There you can download a demo that walks through a real-world example of how this solution extension comes into play during an SAP software upgrade.

In an upcoming article, we will explore the Build and Test phase and look at the relevant solution extensions for that ALM stage.

Kishore Bhamidipati ( is an enterprise software products professional with experience defining and driving product and marketing strategy at large companies like Oracle, Mercury, and HP, as well as startups. At SAP, Kishore is responsible for defining and driving the global marketing messaging and strategy for the IT-oriented SAP solution extensions.

 1 See “8 Must-Have Tools for Your ALM Toolkit” by Kishore Bhamidipati in the April-June 2010 issue of SAPinsider. [back]

2 Requirements are capabilities that a project outcome (a finished product or service) must have. They can be functional or non-functional. Functional requirements are action-oriented tasks — for example, steps that must take place. Non-functional requirements describe, for example, how a final screen layout should appear. [back]

3 A modeling language is any artificial language that can be used to express information, knowledge, or systems in a structure defined by a consistent set of rules. The rules are used to interpret the meaning of components in the structure. A modeling language can be graphical or textual. [back]

4 The business architecture includes the planning and documentation of processes with several levels of detail. It supports the governance of business processes and promotes their standardization across organizations. [back]

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!