Software Engineering: COCOMO & Requirements
Uploaded by
Hazael Estabillo LopezSoftware Engineering: COCOMO & Requirements
Uploaded by
Hazael Estabillo LopezCommon questions
Powered by AICOCOMO defines three project modes: Organic, Semi-detached, and Embedded. Organic mode features simple projects, smaller team sizes, and teams with good application experience working with less rigid requirements. An example is a thermal analysis program for a heat transfer group . Semi-detached mode involves intermediate size and complexity projects, with teams having mixed experience to meet a combination of rigid and less rigid requirements, exemplified by a transaction processing system with fixed hardware and database software requirements . Embedded mode includes projects that require development within strict constraints of hardware, software, and operations, such as flight control software for aircraft .
Functional requirements can be documented as traditional requirements statements, use cases, scenarios, or user stories, depending on an organization's approach to software development . Nonfunctional requirements, on the other hand, may be captured as narrative statements, formatted templates, or acceptance criteria . Each format offers varying levels of detail and clarity, catering to different stakeholders or phases of development.
Functional requirements specify what the software must do to meet user needs, describing product capabilities such as "Determine Claimant Eligibility" or "Pay Claim" in a claims system . Nonfunctional requirements describe quality attributes, constraints, and external interfaces, often focusing on system-wide attributes like availability, maintainability, or performance . While functional requirements are centered on tasks the software performs, nonfunctional requirements address the quality and operational constraints of how those tasks are performed.
Nonfunctional requirements are considered 'global' because they often apply to the entire system rather than individual functions . They include attributes like performance, reliability, and security that need to be consistently managed across all aspects of the product. However, their scope can vary; for instance, 24×7 availability might be necessary for some system users but not others, indicating that while these requirements are generally broad, they do adapt based on specific usage scenarios or user needs .
A project is categorized as Semi-detached in the COCOMO model when it involves intermediate complexity and size, requiring a team with mixed levels of experience to handle both rigid and less rigid requirements. An example is a transaction processing system that operates under strict terminal hardware and database software specifications, necessitating a nuanced approach balancing control with flexibility .
In a health insurance claim system, functional requirements include processes like "Determine Claimant Eligibility," "Adjudicate Claim," and "Pay Claim." Each of these high-level requirements can be further broken down; for example, "Pay Claim" includes sub-requirements such as "Determine Payee," which decide whether payments are made to the insured party or the service provider .
COCOMO Embedded mode is characterized by the need to develop software within tight hardware, software, and operational constraints. This integration is crucial for high-stakes environments where flexibility can mean failure. An example of a project in this mode is flight control software for aircraft, where precision and adherence to constraints are critical for safety and performance .
The 'ilities' are a key component in defining nonfunctional requirements as they represent quality attributes necessary for a software product's effectiveness. These attributes include availability, maintainability, performance, portability, reliability, robustness, security, scalability, testability, and usability. Each addresses a different dimension of user satisfaction and system capability, influencing user experience and operational efficiency .
Capturing nonfunctional requirements as narrative statements allows for comprehensive descriptions that can foster a shared understanding among stakeholders, but may lack uniformity and lead to inconsistent interpretations. In contrast, formatted templates provide structure, consistency, and easier comparison across requirements, though they may constrain the detail and elucidation of complex attributes, possibly missing nuances critical to system quality .
Requirements statements provide concise, clear descriptions of expected software behavior, facilitating quick assessments and prioritization. However, they can lack context and may not fully convey user interactions. Use cases, on the other hand, offer detailed user-centric scenarios that clarify interactions and outcomes, beneficial for aligning with end-user needs. The trade-off is their complexity and the potential for time-consuming documentation, which can slow initial project phases and introduce variations in interpretation if not clearly standardized .