Analysis

Links
What is the best way of designing classes/models any good pattern for it ?

Rémy Fannader • Always start with the distinction between persistent and transient business object, the former with a life-cycle set independently of applications, the latter with a life-cycle limited to application. http://caminao.wordpress.com/how-to-represent-objects-and-activities/identities-2/ Then, set apart structural from functional connectors. http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/connector-patterns/ Third, consolidate with aspects. http://caminao.wordpress.com/2012/02/01/objects_with_attitudes/

Analysis emphasizes an investigation of the problem and requirements, rather than a solution. The term is divided into distinct areas:
 * Requirements analysis: An investigation of the requirements. May include stories of how people use the application written as use-cases.
 * Object-oriented analysis: An investigation of the domain objects - the concepts in the problem domain.

Requirement artifacts

 * Vision: Summarizes high-level requirements that are elaborated in the Use-Case Model and Supplementary Specification, and summarizes the business case for the project. A short executive overview document for quickly learning the project’s big ideas.
 * Use-Case Model: Mainly used for Use-case text stories, widely used to discover and record functional (behavioral) requirements. They are typical scenarios of using a system. The model contains:
 * Use Case Diagram
 * Use Case Text
 * Analysis:Operation Contracts
 * Analysis:System Sequence Diagram (system events that are derived from the use case text.
 * Supplementary Specification: Basically, everything not in the use cases. This artifact is primarily for all non-functional requirements, such as performance or licensing. It is also the place to record functional features not expressed (or expressible) as use cases, e.g. a report generation.
 * Analysis:Domain Model: The most important model in OO analysis. It illustrates noteworthy concepts in a domain. It can act as a source of inspiration for designing some software objects and will be input to several artifacts. The related use case concepts and insight of experts will be input to its creation.
 * Glossary: In its simplest form, it defines noteworthy terms. It also encompasses the concept of the data dictionary, which records requirements related to data, such as validation rules, acceptable values, and so forth. The Glossary can detail any element - an attribute of an object, a parameter of an operation call, a report layout, and so forth.
 * Business Rules: Also called Domain Rules, they capture long-living and spanning rules or policies, such as tax laws, that transcend one particular application. They may be recorded in the Supplementary Specification, but because they are usually more enduring and applicable than for one software project, placing them in a central Business Rules artifact (shared by all analysts of the company) makes for better reuse of the analysis effort.

Finding Requirements
To find and manage requirements, use techniques such as writing use cases with customers, requirements workshops that include both developers and customers, focus groups with proxy customers, and a demo of the results of each iteration to the customers, to solicit feedback.

Categories of Requirements
It is helpful to use FURPS+ categories as a checklist for requirements coverage, to reduce the risk of not considering some important facet of the system.


 * Functional: Features, capabilities, security
 * Usability: Human factors, help, documentation
 * Reliability: Frequency of failure, recoverability, predictability
 * Performance: Response times, throughput, accuracy, availability, resource usage
 * Supportability: Adaptability, maintainability, internationalization, configurability

The "+" in FURPS+ indicates ancillary and sub-factors, such as:
 * Implementation: Resource limitations, languages and tools, hardware, etc.
 * Interface: Constraints imposed by interfacing with external systems
 * Operations: System management in its operational setting
 * Packaging: E.g. a physical box
 * Legal: Licensing and so fourth

Some of these are the software quality attributes, having a strong influence on the system's architecture. [1]