Stats
Actions
Tags
From problem-based-srs
Creates a high-level abstract representation of a software solution from Customer Problems. Step 2 of Problem-Based SRS methodology for designing system boundaries and components.
How this skill is triggered — by the user, by Claude, or both
Slash command
/problem-based-srs:software-glanceThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **Step 2 of 5** in the Problem-Based SRS process.
Step 2 of 5 in the Problem-Based SRS process.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 RFC 8174 when, and only when, they appear in all capitals, as shown here.
Note: In Customer Problem notation,
must/expects/hopesare classification verbs indicating severity class; they are not BCP 14 normative keywords.
| Aspect | Boundary |
|---|---|
| This skill does | Design the first abstract representation of a software solution |
| This skill does NOT | Specify Customer Needs, define Software Vision, or write Requirements |
| Input from | Step 0: Business Context (business-context skill) + Step 1: Customer Problems (customer-problems skill) |
| Output to | Step 3: Customer Needs (customer-needs skill) |
A Software Glance (SG) is the rough idea of a software solution that emerges after understanding customer problems. It represents what is in the software analyst's mind as an abstract view of the solution—the very first representation before detailed analysis.
What a Software Glance IS:
What a Software Glance is NOT:
SG vs Software Vision: The Software Glance is a rough starting point; the Software Vision (Step 4) enhances it with positioning, stakeholder analysis, feature lists, architecture decisions, and environment constraints. Do not add these details here.
🔗 See also: Software Vision (Step 4) — drills down from this glance into detailed positioning, features, and architecture.
This skill expects output from the business-context skill and the customer-problems skill:
The structured business context document (00-business-context.md) containing project identity, business principles, stakeholders, domain boundaries, constraints, and success criteria. This provides the foundational understanding for designing the solution.
Problems expressed using this notation: [Noun] [Verb] [Object] [Penalty]
| Element | Description |
|---|---|
| Noun | Subject suffering the problem (company, stakeholder, customer) |
| Verb | Severity: must (obligation), expects (expectation), hopes (hope) |
| Object | The difficulty that is the source of the problem |
| Penalty | Cost, pain, or consequence (optional if evident) |
Note: If you don't have properly formatted CPs, first use the
customer-problemsskill.
Synthesize a Software Glance by analyzing Customer Problems and producing an abstract solution view.
STOP when you have produced:
DO NOT PROCEED to specify Customer Needs, Software Vision, or Requirements.
## Software Glance: [Solution Name]
### Description
[3-5 sentence narrative: what the software will do, who interacts with it, main interfaces, how data is managed. Use natural language, not bullet points.]
### System Diagram
```mermaid
%% Mermaid block diagram showing system boundaries, actors, and main interfaces
%% Use flowchart, C4Context, or block-beta as appropriate
Actors:
External Systems:
| Interface | Type | Connected To | Purpose |
|---|---|---|---|
| [Name] | [Web/LAN/API/Local] | [Actor/System] | [Brief purpose] |
[What data MUST be stored, where it originates, general persistence needs]
| CP | How Glance Addresses It |
|---|---|
| CP.1 | [Brief explanation] |
### Handoff to Next Step
After generating the Software Glance, instruct the user:
> ✅ **Software Glance complete.** To continue the Problem-Based SRS process:
>
> **Next Step:** Use `customer-needs` skill to specify Customer Needs based on this Software Glance and the Customer Problems.
>
> The Software Glance provides boundaries and direction for identifying what outcomes the software must provide.
## Constraints (Scope Boundaries)
| DO | DO NOT |
|----|--------|
| Keep descriptions conceptual | Specify functional requirements |
| Define system boundaries | Define software architecture patterns |
| Identify interfaces and actors | Detail interface behavior or protocols |
| Note data persistence needs | Design database schema |
| Trace back to CPs | Specify Customer Needs (that's Step 3) |
| Use natural language narrative | Use technical specifications |
| Use Mermaid UML diagrams for system overview | Create detailed architectural diagrams |
> **Boundary Check:** If you find yourself writing "The system shall..." or describing user stories, STOP—you are entering Requirements territory. Return to conceptual description.
---
## Example
**Input:**
Business Context:
> A company has strong difficulties to effectively build relationships with its clients and is convinced that an information system such as a CRM can contribute to reduce these difficulties.
Customer Problems:
- CP.1: The company **must** ensure communication channels with all clients **otherwise** loss of contact affecting sales.
- CP.2: The company **must** consider statistics about customer feedback **otherwise** customer dissatisfaction and losses.
- CP.3: Clients **expect** the company answers their feedbacks **otherwise** frustration and reputation decrease.
- CP.4: The company **must** align sales strategies with customers' behavior **otherwise** miss sales opportunities.
**Output:**
```markdown
## Software Glance: CRM Software
### Description
The CRM software will interact with clients through a web interface allowing marketing, promotions, receiving feedbacks, and sending answers to clients. The CRM software will provide local interfaces to interact with the Manager. Data about clients, feedbacks, and sales history will be stored in a local database. The CRM software will include a LAN interface with the Sales Management Software.
### System Diagram
```mermaid
flowchart LR
Clients([Company Clients])
Manager([CRM Manager])
AccMgr([Account Manager])
SalesSW[(Sales Mgmt Software)]
Clients -- "Web: feedback, promotions" --> CRM[CRM Software]
CRM -- "Web: marketing, answers" --> Clients
Manager -- "Local: statistics, reports" --> CRM
AccMgr -- "Local: response management" --> CRM
CRM -- "LAN: sales data sync" --> SalesSW
SalesSW -- "LAN: purchase history" --> CRM
CRM --- DB[(Local Database)]
Actors:
External Systems:
| Interface | Type | Connected To | Purpose |
|---|---|---|---|
| Client Portal | Web | Company Clients | Marketing, feedback, promotions |
| Manager Dashboard | Local | CRM Manager, Account Manager | Statistics, response management |
| Sales Integration | LAN | Sales Management Software | Sales data synchronization |
Client contact information, feedback records, interaction history, and sales data stored locally. Data originates from client web submissions and Sales Management Software integration.
| CP | How Glance Addresses It |
|---|---|
| CP.1 | Web interface provides communication channel |
| CP.2 | Database stores feedback; Manager interface shows statistics |
| CP.3 | Manager interface enables viewing and responding to feedback |
| CP.4 | Integration with Sales Management provides behavior data |
---
## Validation Checklist
Before accepting the Software Glance output:
- [ ] Every CP appears in Traceability table with explanation
- [ ] Description is narrative style (3-5 sentences, not bullets)
- [ ] Mermaid UML diagram included showing system boundaries, actors, and interfaces
- [ ] No functional requirements or "shall" statements specified
- [ ] No Customer Needs specified (that's Step 3)
- [ ] No architecture patterns or technology choices (that's Step 4)
- [ ] System boundary clearly separates actors from external systems
- [ ] Each actor has a corresponding interface in the Interfaces table
- [ ] Data considerations address what CPs require
> **Scope Violation Check:** If output contains user stories, detailed features, architecture decisions, or requirement specifications, reject and regenerate focusing only on the abstract solution view.
---
## Process Navigation
| Step | Skill | Status |
|------|-------|--------|
| 0 | business-context | ← Input |
| 1 | customer-problems | ← Input |
| **2** | **software-glance** | **Current** |
| 3 | customer-needs | → Next |
| 4 | [software-vision](../software-vision/SKILL.md) | 🔗 Drills down from this glance |
| 5 | functional-requirements | |
**Next:** Use the Software Glance output with `customer-needs` skill to specify what outcomes the software must provide.
---
## Reference
- Gorski & Stadzisz (2016). *Problem-Based Software Requirements Specification*
**Version:** 1.2
**Step:** 2 of 5
**Next:** customer-needs skill
npx claudepluginhub rafaelgorski/problem-based-srsTransforms Software Glance and Customer Needs into a detailed Software Vision with positioning, stakeholders, features, and high-level architecture. Step 4 of Problem-Based SRS methodology.
Elicits requirements through structured questioning and generates high-quality SRS documents aligned with ISO/IEC/IEEE 29148 when no prior specs exist.
Generates structured Software Requirements Specifications (SRS) aligned with ISO/IEC/IEEE 29148. Guides iterative questioning to elicit functional, non-functional, and constraint requirements.