Posts

Showing posts from 2022

Non Functional Requirements Component Type Applicability

Image
Non Functional Requirements (NFR) define the constraints or the way Functional Requirements are implemented. NFRs are categorized as different types of constraints.  Those categories are great for the enterprise but don't really help determine which NFRs apply in any given Business Feature. One way to remedy this is to create a second type of categorization that identifies which NFRs apply for a given component type, The individual NFRs in a category may only apply to certain deployable types. Related Video: https://youtu.be/S4MKvpNNcNo Blog (Related):  https://joe.blog.freemansoft.com/2022/06/non-functional-requirements-nfrs-in.html Classic NFR Categorization NFRs are generally grouped with related constraints.  You can find a variety of categorization taxonomies with a quick internet search.  From Wikipedia: Non-functional requirements are often mistakenly called the "quality attributes" of a system. There

Remote work network complexity - VPNs, proxies, split tunnels.

Image
The incredible increase in remote work, continually escalating security concerns, the shift to SaaS providers for office productivity, and exploding bandwidth demands have changed the way companies manage connectivity.  Companies are moving from  always-on network VPNs to a mix of cloud proxies and zero-trust models. Home users connect to all services via public internet connections. Corporations typically block this type of access via IP or geo-location blocking that limit access from corporate networks or remote sites.  Corporations extended internal hardware and security models by providing remote sites and remote users with corporate-owned machines that join the corporate network via VPN. The VPN bridge the local network to the corporate network. They appear inside the company similar to the way they do inside corporate facilities.  This provides all the benefits and risks associated with being inside the network. Remote machine and site breaches give the attacker broad access to

Scaled Agile - Functional Requirements, Features, Non Functional Requirements, Enablers

Image
Value streams are composed of and managed as a set of  Business Features that  represent some unit of business value. Business  Features are defined in terms of Functional and Non-Functional requirements. Product   Owners define the  business requirements and acceptance criteria for a business feature .  Architecture and technical owners associate Non-Functional Requirements with the same Business Features. Functional Requirements and Acceptance Criteria  describe Features Product Owner's point of view.  Non Functional Requirements are a second requirement stream that defines the structure needed to support the Functional Requirements and thus the business system. As an example, the house building equivalent of FRs and NFRs could be the following: Functional Requirements would be the number of bedrooms, number of bathrooms, cabinet types, and the type and color of the flooring. Non Funct

BDD with SpecFlow - Features Scenarios Steps and Contexts

Image
SpecFlow is a tool that bridges the gap between business-level behavior specification and the technical implementations of automated testing. SpecFlow is an acceptance criteria definition and testing tool that makes it easier to integrate Behavior Driven Specifications into software projects earlier, in a shift-left fashion. Business value is defined and modeled as Business Features. Those features are built from more granular components, often called User Stories.  The Feature and User Stories contain sets of Acceptance Criteria that represent the target state for the Feature. The Feature is the top-level construct in Specflow/BDD. Gherkin Business Features are made up of a set of Scenarios.   Each Scenario represents one or more acceptance criteria.  Each SCenario is validated as a single automated unit test or a parameter-driven unit test with a list of parameter sets.  One or more features and their associated scenarios define the criteria needed

Behavior Driven Acceptance Criteria for Features, User Stories and Tests

Image
Behaviour Driven Development (BDD) is an evolutionary outcome of  Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD). BDD focuses on business values and is designed to remind everyone that business outcomes are the top priority. Drive repeated iteration around the desired business outcomes. Projects can often get distracted and drift away from the desired functions. Think “from the outside in”. Focus on the behavior that directly targets the desired business outcomes. Do not start inside a system or with a discussion on how tools can be used. Use a standard notation for describing behaviors and acceptance criteria. Select a form that can be understood by Subject Matter Experts and delivery. Some teams pick a syntax that is friendly to automated test tools. Apply these techniques at the top, working down into the different

Why do internet sites trust that they know who we are talking to or who they are talking about?

Image
We're flooded with data.  Customers and fraudsters have the ability to submit data, purchase services or products, and interact with corporate edge systems.  Every transaction should be wrapped with the following questions. Who are we talking to?  What is the risk if we don't know? Who are we talking about?   What is the risk if we tie it to someone we already know about? What is the risk of poisoning other data? Be skeptical my friend. Video Presentation Presentation Content Speakers notes will be added later

A sordid tale of customer identifiers - the complexity of knowing when we know

Image
Customer identifiers are the keys we use to bind different bits of information together that we believe represent the same person. This can be more complex than it sounds when you take into account the changing amount of what we know, corporate acquisitions, and partner company interactions. Video Presentation Content Speaker's notes to be added at some future date. A corporation, with divisions that each have apps and with partners. The corporation runs with a single id per person and handles any merge or separation actions by updating all parties. Conway's law: Architecture and communication paths align with organizational structure. Every team does their own thing. Division IDs are bound to the corporate ID at the corporate level. Corporate IDs are bound to the division at the division level.   The corporation creates link ids there shared with the other orgs. The other orgs create link ids and share with the parent corporation.

Non Functional Requirements - NFRs - in Software Systems

Image
NFRs are requirements that do not relate to business functionality. They relate to attributes like reliability, efficiency, and portability. Non Functional Requirements are architecturally significant requirements because they impact the system architecture. They are properties of a system that sit outside of specific business features or functionality. NFRs are sometimes called constraints. Other times they are called Quality Attributes. Constraints generally change the shape of architecture or design. Capturing NFRs early is part of a shift left where we surface the non-business value needs earlier in the process. Non-functional requirements impact the system as a whole and are cross-cutting across business features. when the non-functional requirements are done well, you may eliminate 50 to 80 percent of product defects.   Credit: Jamsoft Project efforts really need to be explicit about capturing their NFRs and updating them. Everyone has been on projects where some technical requi