A software feature consists of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements. Many business analysts use features as a way to describe the scope of a project. However, a simple list doesn’t readily show the size and complexity of various features. Nor does quickly skimming a feature list easily reveal the full scope of a project. A feature tree is a visual analysis model that organizes a set of features in a format that makes them easy to understand.

We begin our exploration of information system data fundamentals by looking at types of records applicable to any organization. Records such as     GL ACCOUNT, STAFF MEMBER, and ASSET are well-understood within any organization large enough to warrant information systems supporting Accounting, Human Resources, or Asset Management functions. These functions and record types are well supported today by commercial off-the-shelf (COTS) packages. So well supported, it’s difficult to imagine any organization justifying a decision to develop an in-house solution rather than buy a commercially available one.

This is the first of a series of articles intended to help business analysts deal with the information aspect of information systems during requirements elicitation. Requirements are commonly categorized as either functional or non-functional. Given only these two choices, data requirement details are typically included as part of functional requirements. Some may be recorded separately as business rules. By focusing on data fundamentals for information systems, this series hopes that business analysts will be better able to recognize data-specific needs and document them accordingly. 

A quick way of learning the techniques and skills for becoming a business analyst is to get an internationally recognized certification like ECBA.

ECBA provides a firm understanding and a solid foundation for a business analysis career. It is the entry-level certification from IIBA aimed at professionals stepping into the BA domain.

As an analyst you have to ensure your own understanding of the bigger picture. You have to zoom in and zoom out frequently. You need to analyze either in small initiatives the context under which the ba work will take place. It is possible to get so focused on the solution that your thoughts are stuck only in delivering the solution and forgetting to revisit frequently the alignment with the scope and the context.