Smart Medication Management System: Requirements and Metrics Report

This report provides an analysis of a smart medication management system, focusing on various aspects of its development and implementation. It begins by exploring the importance of requirement collection, differentiating between functional and non-functional requirements. The report delves into specific requirements, such as dispensing medication, monitoring patient adherence, and real-time patient monitoring. It then discusses applying metrics, including function points, for assessing size, cost, and productivity. The report also covers requirement errors, stability assessment, and metrics for requirements size and quality. Furthermore, it examines design metrics, architectural considerations (client/server), and the use of prototyping models. Process metrics, stakeholder involvement, and the importance of reusability and modification are also addressed. Finally, the report touches upon formal validation, software reusability, and key software engineering metrics like testability, encapsulation, and inheritance, drawing references from key sources like Sommerville (2015), Ali (2016), and Kaner and Bond (2017).

 According to Sommerville (2015) explained that requirement collection is a very
important process of software development cycle.
Functional requirement.
Dispensing medication to patient.
Monitoring medication use and important signs.
Monitoring patient adherence and communicates.
Monitoring important signs and symptoms of patients.
Non Functional requirement.
It is portable to support travel and social commitments.
Real-time monitoring of patients.
Alerting, remaindering patient of action to be taken and notifying the required people.
 Applying metric.
Function Points.
Calculating function point .It is used to approximate size Used to predict size or cost and
to assess project productivity.
Requirement errors collected during requirement collection is used in assement of
quality. Errors in requirements are used in assessment of quality.
Frequency request change it is used in assessment of requirement stabilities. Assess
stability of requirements. Time should reduce with Frequency .When not, analyzing of
requirement would have not properly done.
Metrics for requirements are metrics of size made up of functions, complexity and lines
of code. Requirements of quality are analyzed as volatile .Requirements do changes time.
Requirements Traceability Metrics. It is tracing of requirements specification to initial
form from from one level to another level of requirements in a document connecting.
 Client/Server Architectures.
 Design.
Number of parameters.
Learning module with many parameters require a lot time and efforts.
Number of modules.
Modules help in approximation of complicity of system.
The Use Case help during system design and ensuring correct requirements are met.
Metric can be achieved by number of actors, actions and system domain.
Design Metrics .According to Ali (2016) explained that Design metrics are measured
from document of design.The measurement is based on functionality of code.
Design metrics helps to improve software quality.
Complexity, low coupling and high cohesion are import metrics during design.
High Cohesion is a metric in which parts of system are connected together.

 Prototyping Model.
Selecting metric to verify requirements and architecture as related to the process model.
 Goal-Question-Metric produces desired results when it is chosen in metrics
implementation.
According to Kaner and Bond (2017) explained that GQM is used in collection of process
metrics results.
The architecture should be safe to use no harm while using or it can cause damage to
customers
 Safety.
System should be immune and resilient to any attack.
Usability.
Architecture are to be user friendly, easy to learn and use.
Performance.
The architecture should be fast and efficient.
Client optimized for interactive display-intensive tasks; Server optimized for CPU-intensive
operations
 Process metrics are made up of:
Period process takes to be processed.
The man power related to a process.
 Organization should select a model which involves all stakeholder because stakeholder
helps in collection of requirement
Organization should select a model which is fast so as to deliver in time.
Organization should select a process model which supports reusability and modification
because requirements keep on changing.
.
 Metrics are being used to analyses entity by uses of number or values behaviors and
attributes.
Mathematics models or formula are used to predict activities in prediction system.
The formal requirement for validating a measure involves demonstrating that it
characterizes the stated attribute in the sense of measurement Theory.
To validate the prediction system formally you must first decide how stochastic it is, and
then compare performance of the prediction system with known data points.

 The aim of reusability of software is to make production of software low by substituting
development with recycle. Reuse is to reduce the cost of software production by
replacing creation with
 Modification of software is unavoidable. is inevitable
New software requirements keep coming in place while software is in use.
Changes in operation of software;
Faults are always repaired when there is failure.
Upgrade of hardware and software;
System reliability and performance is improved always.
Testability
Encapsulation:
Percent Public and Protected (PAP): Percentage of attributes that are public. Public
attributes can be inherited and accessed externally. High PAP means more side effects
Public Access to Data members (PAD): Number of classes that access another classes
attributes. Violates encapsulation
Inheritance:
Number of Root Classes (NRC): Count of distinct class hierarchies. Must all be tested
separately?
Fan In (FIN): The number of superclasses associated with a class. FIN > 1 indicates
multiple inheritance. Must be avoided
Number of Children (NOC) and Depth of Inheritance Tree (DIT): Superclasses need to
be retested for each subclass.
References.
Sommerville, I (2015). SOFTWARE ENGINEERING Tenth Edition.
Ali ,M ,J.(2016). Metrics for Requirements Engineering.
Kaner, C and Bond , P, W.(2017).Software Engineering Metrics: What Do They
Measure and How Do We Know?
Varshney,U (January,2013) Smart Approach to Medication Management.