Utilize Requirement Modeling in Software Engineering for Functional Specification [FS]

[Waruna]

Introduction

The functional specification is very crucial for requirement documentation and management when all the functional and technical SAP consultants work on SAP RICEFW during the realization of any SAP project.

In this blog post I would like to discuss about requirements engineering standard practices and requirement modeling in high level which can be utilized for Functional Specification derived from requirements documentation.

Requirements Engineering:

• is a set of procedures used to establish the customer requirements from a system including the constraints under which it operates and is developed.
• is a well organized approach to eliciting, organizing, and documenting the requirements of the system, and a set of procedures that formulates and maintains agreement between the customer and the project team on the changing requirements of the system.

Requirements are:

• Statements of needs from a expected system.
• System features and constraints characterization that are identified while the requirements elicitation.

Requirements Activities:

Following diagram depicted activities of requirement engineering process in a high level.

Requirements Types:

Requirements can be classified under following ways.

• Functional requirements
  • Basic subject matter how behave the system and are measured by concrete means such as data values, logic for decision making and algorithms.

• Non-functional requirements
  • Behavioral properties that the required functions must have, such as performance and scalability, reliability, etc.

• Project constraints
  • Recognize the ways of final product must suitable into the world.
  • Integration with some existing hardware, software or business practice.
  • Defined project scope.

• Project drivers
  • Business- related forces.
  • Purpose of the product is a project driver, as are all of the stakeholders.

• Project issues
  • Define the conditions under which the project will be done.
  • Included to present a coherent picture of all factors contributing to the success or failure.

IEEE 830 Documentation Standard for a Software Requirements Specification (1998):

Criteria for a high-quality requirements set are:

• Unambiguous: Every statement has unique interpretation. Terms should be clear and well defined.
• Complete: All major requirements are considered. No items have been disregarded for future definition.
• Verifiable: All functionalities defined as part of the project have a corresponding test to determine whether they have been successfully delivered.
• Consistent: Final product's end users benefit by getting a product that is easy to use enhancing the user experience.
• Modifiable: The cost of change and refers to the ease with which a software system can accommodate changes.
• Traceable: Uniquely identification is required for each referenced requirement.
• Correct: Every stated requirement represents something required of the system to be built.

Requirements Modelling:

Unified Modeling Language (UML)  and Business Process Model and Notation (BPMN) can be used for requirement modeling with graphical representation by diagrams. You can freely use draw.io online application to prepare diagrams.

• Functional Requirements
  • Hierarchy
  • Data Flow Diagrams
  • Use Cases
  • Activity Diagrams
  • Other graphical models

• Data Requirements
  • Entity relationship diagram

• Linking data and functional requirements
• Maintaining the link between textual and graphical requirements documents

Benefits of Models:

• Provide a visual, non-technical representation
• Are easy to understand
• Quick to produce and easy to amend
• Use limited number of symbols with specific meanings
  • implicit presentation of information
  • concise system descriptions
  • enable code generation through CASE

• Minimize redundancy of information
  • effects of changes are easily identified and incorporated

• Use a simple, top-down expansion
  • easy progression between levels of detail
  • convenient review of the overall system structure

Good Requirements Guidelines:

• Add simple direct sentences
  • As short as possible but no shorter

• Add a limited vocabulary
  • Project glossary also recommend

• Focus on results (goal)
• Define verifiable criteria
  • later relate to Acceptance Criterion

In conclusion, with above blog post your are able to get an overview idea of requirement engineering paradigm and possible opportunities to utilize them with sap RICEFW requirement modeling.

Hope you have gained something it and stay tuned for real world scenario with simple examples in my future blog.