Headline

The namespace for software features of the @system

Description

Each feature (i.e., each instance of the present namespace) must be described on the 101wiki by certain elements listed in detail in the metamodel section on this page. In particular, the feature needs to be described informally as a sort of requirement for the @system and it needs to be motivated informally in terms of software concepts, languages, and technologies that can be demonstrated with this feature within the @project.

There are the following features:

• Company: Companies, department, employees
• Total: Total the salaries of employees
• Median: Compute the median of the salaries
• Cut: Cut the salaries of employees in half
• Depth: Compute nesting depth of departments
• COI: Conflicts of interests for employees
• Mentoring: Associate mentors and mentees
• Ranking: Enforce salary to correlate with ranks
• Singleton: Constrain for a single company
• History: Maintain and analyze company history
• Serialization: De-/serialize companies
• Persistence: Persist companies
• Mapping: Map companies across technological space
• Distribution: Distribute companies
• Parallelism: Total or cut in parallel
• Logging: Log company changes
• Browsing: Browse companies interactively
• Editing: Edit companies interactively
• Restructuring: Restructure companies interactively
• Web UI: Operate on companies in a web browser
• Parsing: Parse companies in concrete syntax
• Unparsing: Pretty print companies

The set of all features can also be arranged in a feature model as defined by the following constraints:

• Data requirements
  • Feature:Company (XOR)
    • Feature:Hierarchical company
    • Feature:Flat company
  • Feature:COI?
  • Feature:Mentoring?
  • Feature:Ranking?
  • Feature:Singleton?
  • Feature:History?
• Functional requirements
  • Feature:Total?
  • Feature:Cut?
  • Feature:Median?
  • Feature:Logging?
  • Feature:Depth?
  • Feature:Parsing?
  • Feature:Unparsing?
  • Feature:History?
• Non-functional requirements
  • Feature:Serialization? (XOR)
    • Feature:Open serialization
    • Feature:Closed serialization
  • Feature:Persistence?
  • Feature:Mapping?
  • Feature:Distribution?
  • Feature:Parallelism? (OR)
    • Feature:Data parallelism
    • Feature:Task parallelism
• UI requirements
  • Feature:Browsing?
  • Feature:Editing?
  • Feature:Restructuring?
  • Feature:Web UI?
• More constraints
  • Feature:Depth => Feature:Hierarchical company
  • Feature:Ranking => Feature:Hierarchical company
  • Feature:History => Feature:Total
  • Feature:History => Feature:Median
  • Feature:Web UI => Feature:Browsing
  • Feature:Editing => Feature:Browsing
  • Feature:Restructuring => Feature:Editing
• Emerging and vanishing features
  • Feature:Reporting
  • Feature:Charting
  • Feature:Grouping
  • Feature:Gender
  • Feature:Bonus
  • Feature:Job description => Feature:Job role
  • Feature:Annual employee review

This specification is under construction.

We use the following informal notation here:

• f? means that the feature f is optional.
• f (OR) means that f is an OR feature; any operands may be chosen, but at least one, unless f is optional.
• f (XOR) means that f is an XOR feature; either of its operands must be selected, but not several of them.
• f1 => f2 means that if f1 is selected then f2 must be selected.
• f (i.e., f with strikethrough) means that the feature is only emerging or already vanishing.

The list of constraints should provide some initial intuition about the @system. Detailed arguments regarding the constraints are associated with the individual features. A more formal feature model is underway; see here: https://github.com/101companies/101docs/tree/master/featureModel

Illustration

Feature:Total serves as a good example of a feature of the 101companies System. More specifically, it serves as a good example of a feature for a functional requirement. The feature also serves as a good example for optional sections for illustration, relationships, and guidelines.

Metamodel

• Headline (required): the headline introducing the feature.
• Description (required): the description of the feature from the point of view of requirements analysis or software design or data modeling, when applied to the @system. Thus, the description would say what the system should do, what qualities it should have, or how its software architecture, software design, or data model should be constrained. When applicable, the user of the system should be mentioned appropriately, e.g., the management of the company.
• Motivation (required): the distinguished reasons for the feature to exist in the context of the @project. A feature may exercise interesting software concepts or it may likely to reveal interesting between software languages and software technologies. A feature cannot be motivated solely on the grounds of the human resources domain.
• Illustration (optional): an illustration of the feature (or a pointer therefore).
• Guidelines (optional): a description of guidelines regarding the realization of the feature in specific contributions. For instance, naming conventions may be pointed out, expectations regarding the demonstration of the realization may be described, or restrictions may be imposed on the description of the feature.
• Relationships (optional): explanations regarding related features.
• Metadata (required):
  • The feature must be declared to be, indeed, an instance of Namespace:Feature.
  • The feature must be classified in its role as a requirement.
  • The feature may be linked to relevant online resources.
  • The feature may also be related to any relevant software concepts.